This is the philosophy behind Communique. Everything is content. Templates are content, user data are content, user ACLs are content and — of course — content is content. Interstingly the compiled JSPs are also content, so you can remove them easily with the installation of a single package and force the JVM to recompile them again.
If all these elements can be handled the same way, you can use a single mechanism to install, update and also remove these elements. The CQ package tool is a great thing to deploy new template code (java code) plus the additional ESP files and the other static image snippets. You can access parts of the system which are not reachable by the authoring GUI. But behind the scenes it looks quite different:
- Content (the things you have Communique for) is versioned and can be added and removed online.
- Code isn’t versioned. If the installation of a package were an atomic operation, one could easily switch between different template version. Going back to an older template version would be quite easy, just undo the template installation and restore the version which is live then. Sadly not possible, one solves this be cleaning all template places and re-installing the older template version.
- Day hotfixes and services: a weird construct. Because you cannot exchange them at runtime, these are extrated into a directory system/bin.new; when restarting the content of system/bin is zipped into a file system/bin.$TIMESTAMP.zip and then the content of system/bin.new is copied over to system/bin. A stable mechanism (updates are performed before the CQ core and the services actually start), but it’s really hard to undo hotfixes. No GUI anymore; you need to find the right zip files and manually unzip it to system/bin.
Oh, another thing: older versions of a handle are not content. No possibility to create a package of handles including its history (aka the versions). Only the most recent versions are included.
Things on a content management system 
Well, I must disagree. Not everything is content, even if stored in the same content repository. Source code obviously isn’t and shouldn’t be treated as such. The same goes for templates (which are in fact part of the application) and hotfixes. Not even everything stored under /content is content – very often you will find some configuration pages or content holders there.
I would then rephrase the statement: everything is a page. But only some pages store content. The trick is to find them in your application, focus on them and build your solution around them.
To sum up: “content” is a vital part of CMS. Taking the “everything is content” slogan literally might lead to blurring this vital part and end up in a bad application design.
Jan: Well, CQ contains a lot of different things in a single repository.
So content and template code are accesible via the same mechanisms, can be deployed the same way and for both ACLs take effect to control the access. That makes it real hard, the only different is just, that there isn’t a CSD available for templates and they are executed. But using the same mechanisms for all other operations is quite neat.
Another example: Regular content and its versions. According to your definition it’s real content, but the standard operations (removing and adding via the package tool) cannot be applied.
So from a design and development point of view, you’re probably right; but from an operational view templates are rather content than versions, just because the natural deployment and administration tool (CQ packages) can be used.
Once again – you’re referring to pages. Content (after Wikipedia) means information and experiences created for an audience. It’s not a mechanism around something that defines it, but its purpose. So yes, the mechanism is quite neat, but the “operational point of view” is simply wrong.
I didn’t define content in my previous comment, but according to this definition – versions are not content since they are not “created for the audience”. It’s just a historical state of (any) data. And yes, they can be packaged – you just need to use other tool for that (crx packages).
I also disagree about CSDs – templates have their CSD (template), so do folders (systemfolder) and plain files (genericfile) – but even this “content structure” is just a mechanism inside CMS – neither of these has any semantic value for the end user. User is interested in things such as news, articles, job offers and so on.
Forgive me for being so stubborn about that but it’s the core idea behind Communiqué (and every other CMS, for that matter). I strongly believe that understanding this is the first step to understanding the philosophy of Communiqué you’re writing about.
Cheers,
Jan