Hi Brian,
I believe I know what is happening but the explanation is quite involved so please follow me very carefully.
You did not post a topology diagram but from the outputs you have posted, it appears that both GH.TEA.ROOM and GH.BOOM.GATE are directly connected via a Port-channel link to the HP switch that is the root switch for MSTI 0.
There are two very important observations you will need to keep in mind. First, the HP switch does not support the PVST Simulation mechanism. It speaks MST only, reverting to non-VLAN-aware RSTP or STP on boundary ports, and that's it. Even if it receives PVST+ BPDUs, it will not start any specific PVST+ interoperability mechanism, as opposed to Cisco Catalyst switches. An important consequence is that when the HP switch running MST is connected to a Cisco switch running PVST+, the MSTI 0 instance on the HP will communicate with the VLAN 1 PVST+ instance but other PVST+ instances will not see the HP switch at all. This is because the HP switch does not originate PVST+ BPDUs to be able to speak to individual PVST+ instances on the Cisco switch, and instead, on a boundary port, it reverts to sending and receiving plain (R)STP BPDUs which are always processed in VLAN 1 PVST+ instance on a Cisco switch. You can see this very nicely in the show spanning-tree root command on the GH.BOOM.GATE switch - for VLAN 1, the switch recognizes the HP as the root switch. For other VLANs, it considers itself to be the root switch (as there is no root port identified in the output).
Second, to the HP switch, all PVST+ BPDUs are just multicast frames. It does not process them as BPDUs, rather, it only floods them in their respective VLANs. For PVST+ switches interconnected by the HP switch, the HP simply "isn't there". Again, this can be seen nicely on the show spanning-tree root command on the GH.TEA.ROOM switch - notice that this switch recognizes the HP as the root switch in VLAN 1, but in other VLANs, it considers the GH.BOOM.GATE switch to be the root switch, simply ignoring the HP switch that sits between these two Cisco switches.
Now, when you configure the GH.BOOM.GATE to run MST while leaving GH.TEA.ROOM run PVST+, GH.BOOM.GATE will consider its Po1 to be the root port in MSTI 0 because, obviously, it receives superior BPDUs sourced from the HP switch. So, the Po1 is the root port on GH.BOOM.GATE. However, because GH.TEA.ROOM still runs PVST+, its PVST+ BPDUs are simply flooded across the HP switch and arrive at the Po1 port on the GH.BOOM.GATE. So this root port on GH.BOOM.GATE also becomes a boundary port.
For an MST boundary port to be a consistent root port on Cisco switches, the consistency rule states: If an MST boundary port becomes a root port for MSTI 0 (obviously because it receives superior BPDUs, either MST BPDUs or VLAN 1 PVST+ BPDUs), it must guaranteedly be a root port towards all PVST+ instances out there. This is verified by looking at PVST+ BPDUs for VLANs 2 and higher, and making sure they are identical or even superior to the MST/VLAN1 BPDUs that caused the boundary port to become the root port for MSTI 0 in the first place.
However, note that this rule can never be met in your network! Because the HP switch does not perform PVST Simulation to speak to PVST+ switches in individual per-VLAN PVST+ instances, GH.TEA.ROOM can never learn about the HP as the root switch in VLANs 2 and higher. Because GH.BOOM.GATE considers its Po1 port as the root boundary port, it is not going to replicate the MSTI 0 data into per-VLAN PVST+ BPDUs (this would be only done on designated boundary ports, not on root boundary ports), and instead, it is just going to check for all received PVST+ BPDUs to meet the consistency check described earlier. So GH.TEA.ROOM effectively stops hearing any PVST+ BPDUs whatsoever, and will soon start considering itself as the root switch for VLAN 2 and higher and start sending its own PVST+ BPDUs. Obviously, these are inferior to the BPDUs originated by the HP switch that made GH.BOOM.GATE choose its Po1 port as the root port, but GH.TEA.ROOM has no way of knowing that. As a result, GH.BOOM.GATE is truly receiving PVST+ BPDUs that are inferior to the MSTI 0 BPDU received from the HP switch, failing the consistency check and causing the Po1 become blocked.
Interestingly, in your show logging output, the inferior BPDU reported by GH.BOOM.GATE actually advertises GH.BOOM.GATE itself as the root switch in VLAN 4. I tend to believe that this BPDU was probably a Topology Change BPDU during the time when GH.TEA.ROOM still considered GH.BOOM.GATE a root switch for non-VLAN1 PVST+ instances (were you running Rapid PVST+?). In any case, within 20 seconds at most, GH.TEA.ROOM should have proceeded to treat itself as the root switch in non-VLAN1 PVST+ instances and this inferior BPDU should have been reported on GH.BOOM.GATE.
There is no simple solution to this problem. One way of solving this problem would be to set the HP MSTI 0 priority to 4096, and before connecting a switch running PVST+, leave its VLAN 1 priority at 32,768 while setting the priority for all other VLANs to 0. This will make the PVST Simulation on Cisco switches happy while keeping the HP as the root switch for MSTI 0.
Another solution would be to configure the HP switch to entirely block the PVST+ BPDUs. A loop-free topology will still be maintained in the network thanks to the interoperation of VLAN 1 IEEE STP and MSTI 0 while preventing the PVST+ BPDUs to wreak havoc with the PVST Simulation. I do not know, however, if the HP switch is capable of filtering frames based on their destination multicast MAC address. If it is, filtering the frames destined to 01:00:0c:cc:cc:cd would do the trick.
I hope this helps but please feel welcome to ask further!
Best regards,
Peter
