Re: Port EVM Livetree #Collective smart contracts to Bitcoin network -
Many thanks for the links @n0nce! I've started learning RGB schema and Taro. From my initial install I see
1) It could be too expensive to execute this on chain
RGB and Taro solely run off-chain by default.1) It could be too expensive to execute this on chain
3) Both seem far away from any kind of production-readiness (documentation is terrible, sample code is full of issues)
That's true; but this just means yours could be the first well-written, working, published RGB smart contract. 
4) Both solutions appear quite hacky. I mean Bitcoin just isn't designed to do this in my opinion.
That's why these protocols are created; to be designed to do this.B) Create a completely separate Bitcoin Bridge Layer blockchain-VM (perhaps WASAM based) that sits on top of Bitcoin and has very tight coupling so to perform ONLY very simple pre-existing Bitcoin opcodes (OP_(Math and bools) and within a maximum execution limit to ensure it is always cost free (let's say 21 operations to keep miners happy:). Perhaps this Bitcoin Bridge Layer could then support different VMs and tooling such as EVM or Substrate/Polkadot or whatever else is flavour of next month. Whether the Bridge Layer is true Turing complete or not, perhaps, then just become irrelevant as Bitcoin is and the bridge will discard anything that falls outside of 21. This would have the advantage of opening up Bitcoin to a whole new set of developers and pre-existing dev tools.
Any such bridge needs to be off-chain and at least mostly Turing-complete; if it was as 'tightly coupled' as you said, it wouldn't be flexible enough and making it 'looser' will not work on L1 without hard fork. That's why it's on L2... which is exactly what RGB and Taro are doing.Why are you a critic of Lightning Labs incidentally?
2 examples:https://bitcointalk.org/index.php?topic=5386437
https://bitcointalk.org/index.php?topic=5387173