Personally, I think the answer is not to support any particular encapsulation or Ethertype in frames on an interconnect, but to be able to deliver kind of Ethernet frame to an instance. Service should really conform to MEF E-LINE standard, or close to it. Basically, take Ethernet frame off the wire, map that to Vlan 'X' across the fabric, and deliver those frames to an instance encapsulated with an 802.1q header of Vlan 'X'. Whatever is inside that, be it 0x8000, 0x8100, 0x88a8, 0x0806 should transit exactly as it was on the ingress service/port. Regardless of the type, or number of stacked vlan headers, or even if there are a mixture of different types coming in. Supporting all Ethernet like this is the only way really to support all use cases. Picking any specific combination of encapsulations and building support for that, especially support that needs to be aware of that encap or match fields, is not going to meet every requirement, and likely be complex.

We have an immediate need with a customer that needs QnQ from fabric into Metal to extend their platform to us. This request is coming in pre-sales meetings more often now as well.

This support is also needed by a customer who brings cross-connect and wants QinQ support. Right now manual config is applied by netops. Deploying on-demand will be a challenge as they will be involved every time.