Extended Voice Actions:
The discussion about how applications work with the new voice interaction service may be a little misleading. As with Now on Tap, applications here don't directly interact with Google; rather they go through a platform API (https://developer.android.com/reference/android/app/VoiceInteractor.html for those who care) which interacts with the back-end speech recognition service. So I wouldn't describe this as developers plugging in to the Google App -- they are using the platform API, which has a back-end plugged in to it (by default via the Google App) that does the recognition.
This is very much how Now on Tap is integrated into the platform, as described in the previous section. In fact, it isn't very much like, it is it! Now on Tap and the new voice interaction are all part of the currently enabled VoiceInteractionService, which is what you are selecting when you select which assistant you want. (This is also why voice actions can now use the context of what you are currently looking at to help with the recognition, because it is also the assistant so it that can do that.)
So, it wouldn't make sense for this to move to a Google Play Services API, because it is a very well-defined platform API. This also isn't really the first time this pattern has appeared: it is basically how input methods work, where platform APIs arbitrate interaction between the application and the current back-end input method. More closely, speech-to-text and the old simple speech recognizer are both pluggable components, which applications interact with through a (simple) platform API to whatever back-end implementation the user has selected.
On the topic of organization of "permissions," while I would agree there is some further cleanup that can happen in the UI, in many cases things are deliberately not simple runtime permissions. For example, the new "Draw over apps" and "Modify system settings" controls actually correspond to existing permissions, which we explicitly didn't want to turn into simple runtime permissions. We want to discourage apps from using them unless they have a really good reason, and they don't have anything to do directly with specific personal data access so are really hard to explain to users.
You'll note there is a warning dialog that appears when enabling an app's access to one of these, giving more information about what is happening. This is also a pattern followed by other existing dangerous access controls like accessibility services and usage access.
Speaking of accessibility, if anything we'd like to see that made less easy for apps to get to. This feature really is intended for accessibility services, and you should be skeptical about any other kind of app asking for access to it -- it gives that app almost complete control over your device and the ability to see everything you do on it!
Also fwiw, the new runtime permissions implementation makes use of app ops for applying permissions restrictions to pre-M applications. You can basically see this as the long desired UI for app ops, and app ops' basic behavior remains the same where turning off access means the app simply sees no data (no location, zero contacts, etc). We never create fake data.
Abuse of high priority messages have a special difference from other things like notifications: they must go through Google servers, so Google can monitor and modify what is being sent to devices. If apps abuse these for other things besides their intended use, we will be able to stop that abuse without touching any software on the device. (Also "abuse" here is much less subjective than for notifications, where there is a large gray area of things some users care about and some don't. For high priority messages, if it isn't something that is time critical to go to the user immediately, it is not appropriate.)
Chrome Custom Tabs:
This isn't really tying an app to Chrome. It is defining an extended API with the browser than an app can use to get the behavior. The standard implementation used by apps should work with any browser as long as it supports the API, regardless of what the default browser is. So Firefox and others should be able to implement the same API as Chrome and get the same behavior from the same apps.