OVN has had experimental support for co-hosted (multiple) ovn-controllers running on the same chassis since v23.03.0:

https://github.com/ovn-org/ovn/commit/ce126c9

Since then most of the functionality has been validated upstream through a few tests:
AT_SETUP([controllers don't touch tunnels that are not on br-int])
and
AT_SETUP([multiple controllers on the same host can talk to each other])
and
AT_SETUP([Encaps tunnel cleanup does not interfere with multiple controller on the same host])
 
However, one of the main issues with the initial implementation was that (at that point) when co-hosting multiple ovn-controllers was the fact that if the two OVN stacks (i.e., SB databases) the two controllers would connect to would require ovn-controllers to use conntrack zones (configure openflow rules using dedicated conntrack zones for local VIFs/routers) there was no way to avoid conflicts.
 
Since then, a new functionality has been added to ovn-controller: the ability to configure per ovn-controller a min/max value for the conntrack zone IDs the controller can use:
https://github.com/ovn-org/ovn/commit/f2363f4
FDP-383
 
The new feature didn't add a unit/system test for the case when this feature is used in conjunction with co-hosted ovn-controllers.  Adding one would validate the remaining untested co-hosted ovn-controller use cases and allow us to remove its experimental tag.
 
The new test should ensure multiple ovn-controllers can manage different ranges of conntrack zones on the same chassis, e.g.:

• different VIFs connected to different br-ints get different conntrack zones
• conntrack flushing works fine and one ovn-controller doesn't interfere with the other