For what it's worth: while validating the behavior of our http2 based provider I saw the same behavior you did. That is, when I send a notification using the http/2-based API, I will get an error response if the request is malformed or the token is completely invalid (usually), but if the application has merely been uninstalled, the request will result in a 200/success response. However, in the case of an uninstalled app, the token will appear on the corresponding feedback service a few seconds later. It doesn't matter whether the original request was submitted by the legacy v2 (binary) interface or the new v3 (http/2) interface.I just confirmed this behavior today on the sandbox endpoints.So it seems that you're right, the http/2 and "legacy version 2" interfaces probably go to the same backend, and feedback-service items are generated in the same way they always have been — asynchronously. The difference is that it's a real PITA to recover from an error on the binary interface, and much easier to recover from an error on the http/2 interface. But you still need to consult the feedback service for delayed errors.

That isn't the behavior I'm seeing — the http/2-based service sends errors in about the same situations the legacy service did, and uninstalled apps / expired tokens still return "success" from the initial submission and cause a token to show up on the feedback service, regardless of which submission service they were submitted with.

Have you tried polling the feedback service? (It's under "Legacy" in the documentation now, but from my testing with app push notifications, it's still necessary to use it if you want to disocver that a token has been unregistered. MDM push behavior might be different, I suppose.)