The specific case you describe should be fine in theory, but may not work in practice. For example, if your console has separate ports for control and Dante it may not actually be possible to connect them to the same subnet:
https://groups.google.com/g/qlab/c/Ap3qqn1McMw/m/Cqv1cyoxEwAJ. I'd also advise against a system design that you could easily break by adding a few more bits, unless it is just for one show.
For a reliable, scalable and future-proof system I would approach it as (at least) 3 "networks": control, Dante primary & Dante secondary. Dante primary and secondary should not share any common infrastructure (switches, cables) that could take down both with a single point of failure. Computers will need 2 NICs – one for DVS and one for everything else. 3 NICs if you want redundant Dante (needs a proper card I think) or access to the secondary network from Dante Controller.
You can build this as 3 physical networks or 2 physical networks with VLANs to run control and Dante over the same switches. With some clever trunking and loop protection you can incorporate redundancy for the control network by having it's VLAN travel down both primary and secondary links.
Presumably lighting won't actually be on the same network as you'll convert from IP to 5-pin MIDI at the point your two systems connect?
If nothing else, I would look to use VLANs to create a second network for non-Dante traffic on any existing infrastructure. Bandwidth is unlikely to be the limitation – it will be about what settings you can configure on your devices to share the same network.
Rich