Indeed, but what I have in mind would be to have several versions installed in the same wiki. Each standard extension would be made entirely read only. Then, a user willing to customize for instance the BlogSheet would create a page MyBlogApp.BlogSheet elsewhere, which would contain a metadata hinting at the fact that this page should have priority over the standard Blog.BlogSheet (possibly a bit like the alias feature idea, not sure).
I have not investigated much but I was wondering if it could make things easier for upgrades: the standard extensions would be installed without risk since they are read only. The ones that got customized in the wiki would live together with the new standard ones, and would be merged step by step. Once they have been successfully merged, the customized versions would have priority again over the standard ones.
We could draw an analogy with Eclipse plugins (as discussed with @caubin some time ago): Eclipse is both made of plugins, and used for creating or customizing plugins, just like XWiki. When a new version of Eclipse is installed, it comes with all its new or updated plugins, and the customized ones are present in the new environment but they live in their own area, I guess: they do not override “physically” the original ones, do they? They probably inherit from some public classes, or use extension points rather than strict physical overrides? “Physical” overriding eases the customization process but at the cost of a high upgrade cost process in my opinion, not sure though.