Is discovery good enough for wider use cases

This week I reviewed the roadmap for the 200 sites my company manages and I wrote-off implementing Web Intents for the share buttons. The reason being if there is no isRegistered type functionality we don't believe we can deliver the right level of UX. We don't want to invoke the Web Intents UI unless we know the user already has a service registered that supports the verb/data type we are requesting.  
 
I know this subject has been covered in detail before and the fingerprinting issue has stopped this feature being added to the specification. The Chrome UI design suggests services that have been registered on the Chrome Store, this goes some way to answering the problem but it has a number of issues. For the lightest weight interaction such as sharing a URL it causes a considerable cognitive load. There is too much to read and understand, never mind the additional interaction, compare this to the simplicity of something like Facebook's 'Like' button.  In my view not having an isRegistered type function will lead to much more complex user experiences being designed into the browser UI's.

Can we not come up with a pragmatic half-way house like a isRegistered function that limits fingerprinting rather than looks to avoiding it altogether? A function that returns true/false against a given verb/type combination i.e. image/* - share.  It would follow the rules below:

Will not provide a result during incognito mode; 
Will only provide a result for a pre-defined set of agreed verb/type combinations; 
Can only answer a small number of queries per a browser session per a domain, maybe 3 times.

Even suggesting the above messy solution feels wrong, but I believe it could provide the difference between a feature that has wide adoption against one which is associated with the smaller use case of web apps.  

Glenn Jones