As you have guessed already, OC200 needs to be reachable for the clients which want to use the portal. OC200 itself does not use VLANs. The »Management VLAN« setting in OC200 applies to the EAP's Ethernet interfaces only, but not to the Ethernet interface of OC200.

Even with Omada Software Controller running on a Linux server – where you could force tagged traffic to/from the controller – it's currently not possible to bind the portal functions to a specific VLAN-aware interface while binding the management UI to another VLAN.

I would also like to see more fine-grained control for the interfaces of Omada Controller – not only different interfaces for the mgmt UI and the portal, but also for communication with a mongod already running on the system (instead of starting its own instance). I already did suggest this to TP-Link.

smadds wrote

Given that other configuration is downloaded to the APs by the controller, why couldn't the logos & images be pushed out too? Surely this would be the most secure and sensible way of getting this to work?

For other portal mechanisms (vouchers, user passwords) the portal must be running on a central system such as OC200, else roaming between EAPs would be very hard to implement. In my opinion it would be much easier to implement VLANs in OC200, so portals bound to a VLAN-aware SSID would use this VLAN for the traffic on its Ethernet interface, too.