When I was at Google working on VR there, I was always jealous of Oculus's vertical integration that let them move so much faster than Google's VR team. Working with partner hardware was the biggest time sink in terms of utility gained per hour spent for Google's VR plans and it's going to be a giant drag for Meta. Because of business contracts, there were firewalls in the source code which meant fixing bugs that spanned the stack took forever and there was a bunch of back-and-forth between companies about whose responsibility it is. This is very different from the standard culture of Google & Meta where a dev can (relatively) easily access the source code for any part of the stack and fix the bug without going through tons of red tape.

On top of this, hardware partners have very different goals from the core OS developer (i.e, Google or Meta) who want to grow the ecosystem. So the hardware vendors add various features to their hardware and the OS devs need to add hacks to work around it. In theory, the OS developer writes a "compatibility" doc and requires hardware makers to follow it. In practice, the hardware maker fails to do so and the OS maker has to put in software hacks to work around hardware bugs. And then engineers on the OS team have to waste time chasing these bugs which affect a tiny portion of users but are high priority due to business contracts.

Some of those business contracts made no sense from a VR ecosystem perspective, but Google went through with them for other reasons such as preventing a key phone maker from jumping ship to another OS or company. That's probably what's happening here. Meta doesn't want third-party vendors to build VR solutions on top of AVP or Google's XR OS, so they're offering crumbs to distract other companies.