In CMS-13523 support has been added for XPage Layout below hst:xpages in the HST configuration.

However, there is one use case which has not been supported yet, namely:

Assume there is an XPage document with

+ mydoc
     + mydoc (preview)
         + hst:page
             - hst:pageref = xpage1
             +abcd 
                  + banner1
                  + banner2
             +dcba 
                  + banner3
                  + banner4

and an XPage Layout

+ hst:configuration
    + myproject
        + hst:xpages
             + xpage1 
                + main 
                      + container1 
                          - hippo:identifier = abcd
                      + container2
                          - hippo:identifier = dcba

then when loading the XPage document, the HST render the 'xpage1' from the hst configuration, and replaces the container items from container1 and container2 with the banner1-banner4, done so by matching the nodename with the hippo:identifier. This works fine, and in the CM, any change to the container gets reflected in the XPage document

HOWEVER, assume a developer now decides to add a new container to the XPage Layout. For example it becomes

+ xpage1 
       + main 
              + container1 
                  - hippo:identifier = abcd
              + container2
                   - hippo:identifier = dcba
              + container3
                   - hippo:identifier = dddd

NOW, when a CMS user renders the ALREADY existing XPage document in the Channel Mgr, what to do with 'container3'? Obviously, earlier created XPage documents do not have a container with nodename = dddd.

SO the desired behavior is as follows:

The Channel Mgr CMS User gets to SEE the 'container3' when rendering the XPage document WITHOUT potential container items stored below 'container3' XPAge Layout : skip the container items since these are 'bootstrap items' which should never be added to existing XPage document automatically.
When the Channel Mgr CMS User then adds a container item to the 'container3' the following most happen: The container with name 'dddd' needs to be added to the XPage Document, and the container item must be added to the 'dddd' component

HOWTO

For the above to support, when the channel manager adds a new container item to a container that is not yet present in the XPage document, we need 3 pieces of information

1. The identifier of the hst:xpage node below the DOCUMENT VARIANT
2. The identifier of the XPage Layout container id
3. The identifier of the Catalog Item to be added

This means, that the CM for this use case must invoke a different URL than for containers that already exist since for those, only the container ID and the item ID is enough.

In the HTML comment, we should therefor in case of a container which is only present in the XPage Layout, have the following attributes:

1. uuid attribute should be the uuid of the hst:xpage node below the doc variant
2. the attribute 'HST-Experience-Page-LayoutComponent-Id' containing the uuid of the XPage Layout container
3. the attribute 'HST-Experience-Page-LayoutComponent = true' such that the CM can construct a different rest call when an item is dropped in this container

On the HST Backend, we then need to support a new page composer resource for /hst:xpage which can handle the above interaction. IIRC Michiel E already on a branch has added the 'hst:xpage' resource which we can use for it