Please ignore the comment above, it was supposed to be an answer but I can't delete it.
I have this evening spent some time in a remote session with Deliberant support, and between us we managed to nail down the issues so it now works. I'm posting this information in case it is of help to anyone else in the future.
1) The Deliberant APC web interface will not respond to tagged frames. This requires the switch ports connected to the APC units to have at least one untagged VLAN assigned, and this VLAN to be used for management of the units. By setting the ports at each end to tagged in VLAN2, untagged in VLAN1, and a PVID of 1 the APCs can be managed from VLAN1 while still allowing VLAN2 traffic.
2) Always check your physical switch ports! After trying to get VLAN2 to work over the bridge unsuccessfully the company electrician handily pointed out that he'd moved some cables, but didn't tell the IT department that he'd unplugged anything. He thought he'd put the cables back in the same place, but when we checked during the support call found that the cables were put in the wrong ports.
The support call wasn't a complete waste of time in that it identified (1) as an issue, but had the IT documentation been updated to reflect the remote switch cable configuration having been changed the VLANs would have been working prior to the support call. As it is we would still have had the issue of not being able to manage the Deliberant APC units given that they drop tagged frames directed to their management interface.
Dan
Switches have no concept of subnets. The term is virtual LAN's, VLANs. The management interface on each switch certainly can be on the same VLAN (and subnet). The ring topology requires some flavor of STP to handle the loop prevention of frames.
Best Answer
Normally VLANs are only used within a site or at least within a network that is controlled by a single entity.
It is possible, to carry encapsulated Ethernet traffic (potentially including VLAN headers) over an IP network using a variety of tunneling protocols and it is sometimes done. The problem is that to do so efficiently requires the "underlay" network to have a higher MTU than the "overlay" network.
That is manageable if the underlay network is a network specifically built for the purpose, on most modern network gear it's no problem to increase the MTU a bit to accomodate the encapsulation overhead.
However if the underlay network is not a purpose built network then this is much harder. Ethernet has no protocol for negotiating MTU, so if you want to use a lower MTU on the overlay network you will need to reconfigure every single device. On the underlay side most of the internet won't pass packets bigger than the default Ethernet MTU.
You can work around this by fragmenting the packets, either using IP fragmentation on the underlay or implementing fragmentation as part of the tunneling soloution. However this has problems of it's own, firstly a nieve fragmentation soloution will result in a near-doubling in the number of packets carried by the underlay network. Secondly re-assembly can be an expensive process, especially if the underlay network re-orders packets.