In fact, I am not too much concerned about the override capability. It might be an advantage, but I do not use it or see any use case for this in my applications.
Here are 2 simple scenari that fail with me and that would seem quite an intuitive way to use wicket :
1) You use jQuery in part of the public pages of your website. so it makes sense to add the jQuery contribution in the PublicBasePage.
But as the PublicBasePage contributions come after the children ones, any Panel using jQuery will fail as jQuery will not be loaded yet.
2) Again you want to use jQuery in a page. It makes more sense to put the contribution in the renderHead than in the wicket:head as it is more type safe.
In the page, you want to add a custom jquery one liner. It is then much easier to put this one liner in the wicket:head as it will be in the same html, and much less verbose than doing this in the renderHead.
But again this fails, as currently the default is to have first the wicket:head contributions, and later the renderHead.
I understood that you can re-write your own strategy (even if I am not sure that the wicket:head / renderHead order can be altered), but I am quite reluctant to do so, as this means you might have a component library that can work only with some specific webapps.
Also, those problems are quite nasty, as you do not detect them on compilation.
That's why I would suggest :
1) To have 2 renderHead methods renderHeadBeforeMarkup & renderHeadAfterMarkup (or whatever better name).
At least this make the component libraries completely safe and the coding intuitive.
2) To use the former wicket 1.4 default order which is much more intuitive (and which will have the advantage to limit the breakage in the legacy applications).
This is also in line with the java code where the base class constructor is always called before the sub class one (hence the order assumed in my quickstart which would be the natural one for someone not delving into wicket's code).
The implementation would require implementing a buffer in the HeaderResponse to allow the override of parent contributions by the children (if this is a useful feature - frankly I am not sure).
I guess that would also require an additional method (like header.flush) that would be called in the renderCycle.
With those changes, it would also remove the need to have a configurable renderStrategy.