Yes we're adding it twice which does seem like a bug.

(pcmk__apply_coloc_to_priority)         trace: Applied master-prefers-vpcip to rsc_SAPHana_I13_HDB00:2 promotion priority (now 199 after adding 199)
(set_instance_priority)         trace: Assigning rsc_SAPHana_I13_HDB00:2 priority = 199
...
(sort_promotable_instances)     trace: Adding scores for rsc_SAPHana_I13_HDB00-clone: initial promotion priority for rsc_SAPHana_I13_HDB00:2 is 199
(add_promotion_priority_to_node_score)  trace: Added cumulative priority of rsc_SAPHana_I13_HDB00:2 (199) to score on ib1-az1-dbn1 (now 199)
(pcmk__add_this_with)   trace: Adding colocation master-prefers-vpcip (rsc_SAPHana_I13_HDB00-clone with vpcip using #uname @99) to 'this with' list for rsc_SAPHana_I13_HDB00-clone
(apply_coloc_to_dependent)      trace: Applying colocation master-prefers-vpcip (promoted rsc_SAPHana_I13_HDB00-clone with vpcip) @99
(add_node_scores_matching_attr)         trace: ib1-az1-dbn1: 199 + 0.000099 * 1000000 = 298

Neither pcmk__apply_coloc_to_priority(), add_promotion_priority_to_node_score(), nor apply_coloc_to_dependent() is redundant as of right now (I tested dropping each), so this is going to require some work. Hoping it's not too bad...

Initial results look okay with dropping apply_coloc_to_dependent() and adding a block to pcmk__apply_coloc_to_priority()... I need to mess with it some more. We also might prefer moving logic into apply_coloc_to_dependent() and trying to get rid of pcmk__apply_coloc_to_priority() instead, if possible.

Side note, the test input itself is intriguing. The summary wouldn't change even if this issue were fixed and the scores were applied correctly. So the problem shouldn't have been noticeable with this particular input.

It's noticeable solely in the scores

yeah I just meant that I usually wouldn't check scores unless they're affecting the behavior somehow, so I'm surprised this was found