The second example has already been fixed with the microphone indicator from 1-2 versions back, where a light shows up in the corner whenever the microphone has been activated (and swiping down tells you what app activated it). A notification could be added if an app tried to activate the microphone when it wasn't in the foreground (but I don't think the OS lets you do that anyway?)
You'd think that maybe restricting connections to e.g. domains that are rooted in a zone the developer has proven ownership of, would be fine... but there are third-party advertising, analytics, and fingerprinting services that allow you to CNAME them as subdomains of your domain to evade ad-blocker signature recognition.
And, of course, no user could ever be expected to figure any of this out if asked in a prompt. "Example App is asking me to allow it to connect to abcdefg.example.com? Well, they own that, don't they? Why wouldn't I allow that?"
ANY "solution" that puts more burden on the user isn't.
The problem with consent prompts on websites is that they are rarely in compliance with the GDPR.
These are the sorts of prohibited behaviors that can be heuristically recognized by technical means (e.g. static analysis), but where any such recognition would necessarily result result in tons of false positives; and so those issues, when raised, must be passed to a team of human auditors for determination.
This is, by-and-large, why App Store submissions — even for updates — still require that human-auditor step. They're always watching for those seemingly-minor "this app got sold to someone evil" updates that slip in spyware — the kind you see often with Chrome Extensions.