Hello @encaf1,
Thanks for the suggestion! We are aware of the podcast:// URL schema protocol, it has been around since as early as 2005. Let me explain why we did not include it. There are four problems…
Non-device support: If you do not have an application on your device that recognizes the podcast protocol, then the user will receive an error. All of the other subscribe URLs will go to a web page with a convenient message stating as such. This is a UX problem.
Lack of support from apps: Last time we looked only a small handful of applications supported it. None of the top 10 apps in our statistics were on the list. The top 10 apps either support the Apple podcasts/Subscribe on Android URLS and/or they provide their own subscribe URLs.
No standard protocol: This is the biggest problem today, it is assumed that podcast:// is actually https://. Today websites should be https. It is true the app developer who supports podcast could try both http and https, or maybe everyone should start assuming it should be https, but it is a complication that the protocol itself cannot address. One solution is to also include the port number, e.g podcast://exmaple.com:443/feed/
podcast:// is not in a standard RFC: If you are not aware, RFC stands for request for comments, the IETF organization is responsible for publishing the RFCs, it is a standard that all protocols related to the Internet use, it is a set or procedures for standardizing a protocol for applications to use. Until this is done, the first 3 problems are left to each developer to decide what is the correct way to handle podcast:// protocol.
We will add this as a feature TODO, but because there is no official standard we may have to offer it as an option for advance users.