This is Google's next Android, with a low latency rendering pipeline for the next generation of mobile devices.
Hey, I'll bite. Let's see.
Having been to the last several I/Os where the question is asked at the fireside chats, the answer has always been "right now...". No one is saying dump Java, but if we could get some native hooks through something like Dart, that would be pretty awesome.
You can, of course, move the Android middleware layer to other OSs, for Android compatibility. Which is how you can run Android apps alongside Tizen apps: https://youtu.be/nmiHPcHGgSM
Android was designed for one runtime, Dalvik and later ART. But there is nothing preventing a new OS being designed for multiple runtimes that includes runtime support for Android apps.
I'm generally not sympathetic to Java complainers. If you have Android Studio, or any other decent IDE, verbosity isn't a problem. But an OS built for Dart apps and a Dart UI stack would be the logical next step.
It will share nothing with the present Android architecture initially. They'll probably shove in an Android sandbox, so that you can run some existing Android apps and stick them somewhere in your virtual space. But those won't be native apps on this new platform.
The new apps will have drastically different needs, input methods and such.
Consider the simple example of a new turn-by-turn navigation app. It will have a waypoint shown in your field of view, with an arrow pointing to the next waypoint after it. It has to 'stick' in a virtual location that corresponds to a physical one.
There's no way to do that sort of thing with the existing Android API, the concepts simply don't exist. Rather than have everyone write their own (like video games do that implement navigation inside the game world), they'll create a new API for this. And a whole new operating system.