That's only the case if one wants to integrate with Google ecosystem. Every single mobile app with a more than rudimentary casting capabilities has a custom receiver built by the developer of the application. When we built ours the only real issue were Google's funky interpretation of CORS rules and sucky documentation.
However I'm still unclear... if the goal is to render output on Chromecast, a combination of ability to render web pages, video and audio streams and images seem to cover pretty much everything needed to interact with the device.
Yes, that's what I meant: you can cast to the chromecast, but you can't substitute for it nearly so easily. The client is open but the server is closed.
I believe the applications have to be registered with Google? (Who presumably can ban them?)
I am pretty sure you're correct and we had to register our app.
My point is why not push media/web pages using something like catt bypassing all the mess? I certainly see the appeal of using anything with HDMI port to push the media out but RPI and likes aren't anywhere close to Chromecast dongles in polish and what one needs for adoption is ease of use.
You don't have control over the services that "pushes". So yes, we can figure out our own streaming push feature as you describe. But getting an existing item (e.g. chrome) to push to your custom server is impossible.
If content providers ( remote sites ) don't support the device for a push via whatever streaming protocol the device uses then the device has to have a pull proxy to interpret the content in addition to rendering it over HDMI.
The point is we already have a cheap HDMI renderer that can be connected to a network, has a fantastic form factor, most of the needed features, is so incredibly brain-dead simple to use that my wife's mother who can't make a programmable coffee machine work took less than 10 minutes to connect it to watch Netflix and is available in Walmart/Target/BestBuy/OfficeDepot/Staples etc.
The biggest enabler of non-restricted casting would not be a renderer interface. It would be an easy to integrate library in non-geek languages (i.e. not C/C++/Rust/Go but Python, JavaScript, PHP, Ruby, Perl, etc ) with interfaces like PlayMediaFile(chromecastid, url) and RenderWebPage(chromecastid, state, url) to drive a Chromecast from a local box/smartphone without having any support from a content provider.
I have been playing with Jellyfin/Plex/etc recently and they are atrocious in the UX for anyone who is not invested in making them work well because they all try to solve all of the annoying problem of handling and organizing media libraries, pulling media sources together and interfacing with casting devices. They do everything OK, but do nothing well. Give their authors a solid way to cast to Chromecast that just works and we will have an explosion of content to TV solutions.
However I'm still unclear... if the goal is to render output on Chromecast, a combination of ability to render web pages, video and audio streams and images seem to cover pretty much everything needed to interact with the device.