How hard would multiple receivers be?

In general it would be a very useful feature, but it is quite hard to implement IMO...

I doubt the 7E could handle the #1 case, it can't load two modules to work with.

In any case you should guarantee, the two trnasmittion uses different channels.
You would have to provide (edit/store) two selectable protocols (with their options as well), two IDs, and two distinct bind buttons on the GUI.
Plus the channel mapping for the two...

My main concern however is about the timing.
Some protocols (like the DEVO for example) are quite dense, they can transmit in every few ms, and sometimes even receive telemetry data between them...
If you use one protocol for both transmittions, in theory they could be synchronized, but different protocols use different timing, so they will conflict each other...

This was discussed before. I think in regards with dsm2 (but maybe FlySky) which would have enough free bandwidth to transmit two independent sets of packets.
You would definitely lose telemetry capabilities.
Support for 2 different protocols is likely too difficult, each has different timings, so they would occasionally overlap, and the tx wouldn't be able to send both.
The biggest problem is figuring out how to do binding. You probably need fixed-id for at least one of the channels to make it work. Maybe bind it with fixed id as normal, and then afterwards assign the id to tehe upper channels.

Doing something like that wouldn't be too much work, however then we run into the question of whether the MCU has enough processing power. The protocol code keeps the MCU in interrupt mode for a long time (when it can't be doing anything else). Doubling the amount of time there might be too much. So again, it would depend on the protocol.

Not sure which 'it' you mean, but the entire protocol stack runs in interrupt context (medium priority). The only thing that interrupts it will be the rollover timer.