The "material-based renderer" sounds... fluff? Most any system should have it so that rendering a menu is a single line of code. Same for toolbars and other. Those are typically simple registrations of ("name" "description" handler). Anything more that that, and you are doing tailored menu/toolbar and are straying on purpose.
That leads, then, to the spatial windows and APIs that go with them. And... quite frankly, I have zero faith that anybody can pull off a V1 for that API. Expect churn and capability growth.
For the process isolation on eye-gaze tracking... assuming you can get "hover" events for things you are gazing at, than I fail to see how they can keep you from reading the gaze. I expect they will try and lock down abuses of that, but as soon as you enable coding against what a user is looking at, developers will find a way to leak that.
And if they expect that the primary way I will interact with an application is by looking at it.... that feels very very sad, all told. I don't want to just look at things, I want to manipulate them. And for that, I am almost certainly going to want some haptic/tactile interaction. Such that this won't live on its own.
Happy to be proven wrong, of course. And, for what it is, this does look impressive. I just don't buy the marketing spin on it, at the moment. Way way way too "dreams work, bro!"