It's unfortunate how things turned out. only way this makes it in is if a ton of concessions are made or they branch off.
A feature they could add would be direct sidechain support of some kind. This would give the following
testnet <-> elements <-> any standard side chain
This would require a definition of a side chain. It would have to be limited so that it is compatible, but it could still be made pretty flexible.
The specification would only need to define how "unlock" transactions are encoded in the side chain. All side chains would need to have a standard header chain.
A soft fork on mainnet could be used to add new POW (or POS or whatever) hashing methods for side chains.
The merkle tree could be hash(unlock_outputs_merkle_root || sidechain_specific_merkle_root). The side-chain can do whatever it wants with the side-chain specific root.
If this was included with mainnet, then elements itself could use it to connect to mainnet.
A soft fork could add the new opcodes to mainnet.
OP_1 OP_SIDECHAIN_OPERATION
This defines a new side chain. It would include info on how to parse the header chain for the side chain and also how long the lock timeout should take.
New POW algorithms could be added using a soft fork.
A minimum output value could be used to prevent spamming (say 10 BTC)
= hash()
= target of coins on the sidechain (sidechain specific meaning [20 bytes])
= P2SH address to claim the output (valid until the sidechain activates)
OP_2 OP_SIDECHAIN_OPERATION
OP_3 OP_SIDECHAIN_OPERATION
These operations lock the output on mainnet. The refund P2SH is only needed until the sidechain activates.
When more than 1000 BTC is moved to a sidechain, it activates. This locks all funds sent to the side chain for 1024 blocks. This is to give miners a chance to SPV sync with the sidechain's header chain.
1000 BTC might be to low. Potentially, there could be 21,000 side-chains.