Elijah pointed out that putting shapeshifter on 443 does seems pretty important. What is the point of obfuscating traffic and then putting it all on a unique port?
We either need to have another IP in order to do that, or we do not run openvpn on 443 at all.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
I would prefer to keep openvpn on port 443, because it's less overhead. Using sslh or other multiplexers to receive both shapeshifter and openvpn on the same port is fragile. There's another problem with having 2 IPs for 1 gateway (your first idea): the eip.json associates 1 IP per gateway, so another IP for a different transport would require a change and update there as well.
Lastly: if the operators can choose to en- or disable openvpn/obfs4 on 443, that would probably be the easiest today.
I see the problem, that clients, that use RiseupVPN in a restricted network (that blocks 1194 for example) with a client that has no pluggable transports support would fail with my proposed 'fast and easy' solution. One could argue that PT support will be included in all official clients very soon, but maybe not in community clients like rani's shell script.
A per-gateway configuration might be nice, in case a provider might want to mitigate that issue by configuring some openvpn/port 443 gateways without pluggable transports support. That's maybe similar to what you propose in your last point?
I would prefer to keep openvpn on port 443, because it's less overhead.
I don't quite understand why it is less overhead. Running OpenVPN on the default OpenVPN port should not be a bigger issue on the server side, or? The easy solution would include to not use any multiplexer anymore, so OpenVPN runs only on 1194, and Obfs4 runs only on 443.
When we talked in our meeting we decided for the short term that we'd have a three node setup: on the gateway we put openvpn on port 80 and shapeshifter on port 443, on the front-end we'd have geoip on port 443