Attribute based colocation allows reference to a node-attribute in a colocation constraint basically allowing to use the content of that node-attribute to be used instead of a node-name.

When a cluster is e.g. split over multiple sites having multiple nodes on each site one would put the site name into a node-attribute.
When an instance of a resource cloned over the whole cluster would now be promoted we should now be able to have all instances of another cloned resource on the same site to be promoted - given that promoted-max allows enough of the instances to be promoted.

Current behavior is roughly as it would be without the node-attribute given (Just the instance on the same node is being promoted).
With the introduction of a dummy primitive the desired behavior can be achieved.
Dummy primitive follows promoted role of the first clone while promoted role of the 2nd clone is colocated (with node-attribute holding the site-name) with the dummy primitive.
Maybe that can be helpful finding why it doesn't work with just the simple colocation promoted following promoted.

Files attached represent a cib as initially intended (coloc-attr-role.xml) respectively with a dummy primitive (coloc-attr-role-dummy.xml).
The cib has a status-section where stubborn-clone is promoted on nodez01n01 while firewall-clone is promoted on nodez01n01 & nodez01n02 which do reside on the same site.
'crm_simulate -Sx coloc-attr-role.xml' demotes firewall-clone on nodez01n02 while using coloc-attr-role-dummy.xml keeps booth instances of firewall-clone promoted.

What is the impact of this issue to you?

Please provide the package NVR for which the bug is seen:

How reproducible is this bug?:

100%

Steps to reproduce

1. setup a cluster with e.g. 5 nodes and 2 promotable clones with instances on 4 of the 5 nodes
2. 1st promotable clone allows one promoted instance while 2nd doesn't limit the number
3. the 4 nodes consist of 2 sites with 2 nodes each (site name in a node-attribute)
4. setup attribute based colocation that colocates the promoted state of the 2nd promotable clone with the site (via node-attribute holding the site name) where the 1st promotable clone is running promoted 

Expected results

The 2nd promotable clone is promoted on both nodes of the site where the 1st promotable clone is promoted

Actual results

Behavior exactly as without the node-attribute - that instance of the 2nd promotable clone that is running on the node where the 1st promotable clone is promoted is promoted but not the one on the other node of the same site.