Here's a news flash:
Some things in XPages don't work the way you want them to or the way you thought they were going to work or the way IBM said they were going to work.
That's not meant to be a knock of any kind. XPages are an awesome execution of extending JSF and coupling it into a very robust environment but the fact is there are a lot of moving parts and it is complex. The folks at IBM spend their time trying to reduce the complexity of the tool itself and that is hard work so if the odd bug or challenge creeps in in your specific use case...well, so be it.
When you do encounter strangeness, make sure you isolate the issue and test it by itself.
Sounds obvious but when you're knee deep in battle with the code you might feel it is a waste of time to extract code to try and fix a problem.
If your XPage will not work without a bunch of nested custom controls, it will not work with a bunch of nested custom controls.
One development path could be to develop the entire XPage and see if all of the data saves when everything is displayed and it is all in the same page. If it does, great! Now break it up into smaller pieces where pieces are panels or custom controls. etc.
If your XPage does not work and you have it built with custom controls or other dynamic elements, save yourself some time and frustration by removing everything except for the problem and work the problem until it is fixed.
You can do this by making a copy of the original XPage and then tearing down the "live" XPage and then rebuilding it piece by piece until you find the problem or by creating the simplest of XPages and testing the problem there.