Although I've marked this topic as resolved, on the basis that I was happy with Tim's advice to stick with the original solution on the basis of risk, I was still intrigued to discover whether I could make Andrea's solution work. Referring to my reply to Andrea, I commented that I needed some way to skip back through the JSF lifecycle in order that the view would be rebuilt with index.xhtml's <ui:include> tag pointing to the newly selected content page.
Whilst searching for a number of solutions, I came across this post:
http://www.theserverside.com/discussions/thread.tss?thread_id=48227#246767 which describes how to replace the current view with a new one. I've implemented this in the test app detailed previously within this topic and it appears to work fine. The changes that I made are as follows:
PageBean.java
The obvious issue with it is that it's pretty drastic thing to do and I might expect problems with the content around the "included" pages because it completely removes the current view (and therefore any state associated with the components that were in it) and creates a new version of the same one so use it at your own risk.
I don't know enough about JSF to be able to see all of the implications of it but it does answer my previous question which is why I posted it. If anybody has any comments on it, I'd be interested to hear them however as it may be something that I look at again in a future project.
UPDATE:
Instead of creating a new view, I tried calling ViewHandler.restoreView(FacesContext) which appears to work too - I've currently got no idea what ramifications this might have, but the phase listener that I have monitoring the lifecycle isn't really altered. It does however cause the view to be rebuilt - I'm hoping that any component state is therefore preserved as if this had been a normal page navigation?
The updated reloadView() method is below:
PageBean.java
Again, any answers as to whether this is a reasonable thing to do or not are greatly appreciated.