In the repository of the cargo-contract CLI tool, which currently "helps you develop smart contracts in Parity's ink!, which is a Rust eDSL allowing you to write smart contracts for blockchains built on the Substrate framework", there is an opportunity here to extend it to support Solang so developers could use it to write smart contracts in either ink! (which compiles to WASM) or Solidity (which compiles to WASM using Solang compiler), which they could then deploy to chains that implement the Substrate Contracts module. However, they'd need to use a different compiler like solc to compile down to EVM-compatible bytecode if they wanted to deploy it to chains that implement the EVM, so I think the CLI should give them a choice of whether they want to compile the Solidity code to WASM or EVM-compatible bytecode.
If cargo-contract had this feature of also supporting smart contracts written in Solidity then I was thinking it could be valuable for decentralization and adoption of blockchain and Web3 and multi-chain deployment, since developers could more seamlessly build the smart contracts of a DApp that uses a combination of both ink! and Solidity at the same time.
They'd be able to write smart contracts in Solidity that I think would be able to interact with Moonbeam-specific precompiles (EVM bytecodes used to run cryptographic computations within acceptable gas limits) through Solidity interfaces using the Ethereum API, which are ultimately used to interact with the underlying Substrate interface, as shown here.
But the smart contracts written in Solidity (or other languages like Vyper) that use solc to compile down to EVM-compatible bytecode could only be deployed to chains that have a full EVM implementation, such as Ethereum and Moonbeam.
Whilst the smart contracts written in ink! are compiled into the web binary standard WebAssembly with file extension .wasm that may be deployed to chains that have a Substrate Contracts module implementation.
But if in the future chains like Ethereum 2.0 and Moonbeam, and chains implementing the Substrate Contracts module, all supported a gas-efficient eWASM (Ethereum WebAssembly) standard, then most precompiles could become redundant.
Then CLI tools like cargo-contract could compile smart contracts written in ink! and Solidity into eWASM, and they could be deployed to any chain that supported eWASM.
Question: But how would it be possible to build smart contracts written in ink! that call public functions in smart contracts written in Solidity and vice versa? Could the smart contracts written in ink! use Rust FFI to interface with the smart contracts written in Solidity? Or would it make more sense in any case to (or be necessary to) just first transpile Solidity to ink! using a transpiler like sol2ink, and then compile to WASM (or eWASM in future).
Update: It seems like the Solang team have already thought about this possibility here.