Yup. It's one of their theoretical advantages that's about to become a lot less theoretical. Historically it hasn't made much difference because optional instructions were hard for JIT compilers for most languages to use (in particular high level JITd languages tend not to support vector instructions very well). But a doubling of registers is the sort of extension that any kind of code can immediately profit from.

Arguably it will be only JITd languages that benefit from this for quite a while. These sorts of fundamental changes are basically a new ISA and the infrastructure isn't really geared up to make doing that easy. Everyone would have to provide two versions of every app and shared library to get the most benefit, maybe even you get combinatorial complexity if people want to upgrade the inter-library calling conventions too. For native AOT compiled code it's going to just be a mess.

In what concerns the JVM and ART, and the CLR, it is quite practical, even if there is room for improvment.

Gentoo users will finally get to be smug again, once GCC/clang have support for them.

IBM and Burroughs/Unisys have already been doing that for decades, with bytecode based executables for their mainframe/micros.

Or Xerox PARC, with their microcoded CPUs loading the desired interpreter on boot.

I guess, it is an idea that keeps being revalidated.