I found the problem and a work around for my application. I do believe however there is more work that needs to be done defining exactly whether the operations which build the JSF id are a bug or a feature 😉
It appears I had a JSF id collision between my custom widget and header widgets which were in some of the child documents mentioned in my comment above.
Bottom line is the custom widget ID's (JSF component ID's) in the Listings & Views -> Forms Layout used as a global header in each of the edit views of the child documents collided with the ID's generated by Nuxeo Header widgets I was using in each document. The collisions only occurred when I used a custom widget to display the "dynamic" string I mentioned above.
The workaround was to use a generic template/text widget with a value = #{my EL call}. It seems the generic template/text widget generates an ID for the Listing & Views -> Forms Layout "global header" that does not collide with the individual headers generated in the edit views of some of my child documents. The culprit seemed to be the word "template" that was used as a base for the ID with a suffix of one. Both the Listing & View and the individual edit-view software seemed to use the same algorithm to generate the ID's and they are unaware of each others existence hence the collision.
To see this problem create an edit view with a header widget and some text.
Then create a Listing View-> Form Layout with a custom widget which just puts a static string into the value property.
Try to display the edit-view and you should get the duplicate Id error seen above.
