If you check out the registers, you can see that in total there could be at most 16MB of data in the string registers and 256kB of data in the ALU registers. GitHub - AluVM/rust-aluvm: Rust implementation of AluVM (RISC functional machine)
Yes, this is a correct understanding, it grows with every state transition / transfer, however it’s important to note that the this growth is strictly slower than the growth of a blockchain. You only verify the subset of history of a certain asset - and for that asset only, compared to blockchain where everyone verifies everything (all transfers for all the tokens).
It is considered a future concern. Was talking to guys from Bitfinex who are working towards deploying USDT on RGB, they estimated that it would take 2 years in the worst case (for high velocity asset such as USDT) before the history growth starts being a problem (it is also important to note that using RGB over Lightning doesn’t grow the history). But as already discussed here succinct proof systems (SNARKs/STARKs) are considered to be a permanent solution for this issue.
For centralized assets (like USDT) you can even use re-issuance, give the tokens to Tether, they burn them and give you fresh USDT without any history, this could even be done atomically in a single transaction (using scriptless atomic swaps: RGB scriptless atomic swaps · LNP-BP · Discussion #125 · GitHub), such that not even Tether can steal your USDT during re-issuance.
Yes, you are right, I am not that deep in AluVM - I guess Maxim would be the right person to answer these questions. From what I know you can have extensions to AluVM adding additional opcodes, but not sure if those extensions are native or written in AluVM as well.
Also not sure if all the extensions need to be included in the RGB itself or if they can be just included in a specific RGB contract.