At 10 slaves that needs to receive 1Mb/s: I'd argue that you're entering the area of things that should be solved with a dedicated multi-node bus, rather than cobbled together.
Generally, however, the idea of using SPI (with appropriate fan-out buffering, it's not said that any SPI master can drive a bus with 10 slaves at different distances) for broadcast, and I²C as backchannel is sound.
That way, however, you get a highspeed one way, low-speed no-interrupt backchannel, and that might get complicated. As Brian Drummond recommended, having a mux that just assigns the MISO to a single slave would enable you to use "normal" bidirectional mode, with TX being "broadcast" as a "side effect", and that would simplify the bus logic immensely.
I'd argue that for SPI at these rates, 2m is actually quite a lot. It definitely works, if you buffer and carefully design traces and wires, but it's a fragile thing that will need a lot of tuning.
All in all: I think you might be better off with something like ethernet. 10×1 Mb/s doesn't really sound like you're connecting arduinos, anyway.
Look into existing Buses:
- CAN sounds a lot like what you want. 2m, high reliability, lots of broadcast traffic, individual small data replies. I think CAN works very well fro broadcast data, and otherwise "feels" a bit like a multi-master I²C bus. It's commonly available as integrated in MCUs, because it's an automotive bus. It is very proven. I think it's fastest mode runs at 1Mb/s, so you got no headroom there.
- LIN: cheaper alternative to CAN (and basically obsolete because CAN is cheap these days): too slow
- I²C: too slow
- SPI in a shift register ring: Design your own protocol. All your slaves and your master form a ring; data is just shifted through the slaves in one direction in a fixed packet length with a header byte saying from where the data came; many microcontroller's SPI peripherals actually do exactly that forwarding with their RX buffers if you don't modify the TX buffer.
If a slave has something to say, it inserts its own packet. Works if you clock your SPI bus faster than 1Mb/s, so that there's reliably gaps in between broadcast packets. Downside is: own implementation -> bugs, limited segment length, and of course latency.
- Ethernet: Will need Microcontrollers that "speak" to a PHY (MII, RMII, GMII,…) and ethernet PHYs. On a single PCB, you might get away without magnetics attached to these. Upside is obvious (well-tested protocol, including broadcast, unicast, multicast, hardware integrity, mature and easy debugging, prototyping with a goddamn normal PC with a normal network card). Downside: Cost
- USB: Master and slaves speak USB 2 FullSpeed = 12Mb/s. Only allows for point-to-point (as far as I know), will need a USB hub IC, but a very elegant, easy to test, relatively cheap solution. Downside might be firmware complexity.