It's easy to find KML examples that Manifold "doesn't read" if the criterion is that actions possible within KML file are not supported within Manifold.
That's very useful for many purposes, just like browsers are very useful, but it is getting far afield from the idea of interchanging GIS data using file formats.
It's also extremely dangerous for users if you really want to enable all that stuff. For example, it's perfectly possible from a technical perspective to embed a ransomware launcher inside a KML - the entire code of the thing, not just a link to a malware site - and have that fire unknown to the user when they pop open the KML to look at some spatial data.
if Manifold asked if the user wishes to download the linked data accepting the risk?
Sure, of course that would be possible. And it would be possible to sandbox the other dangerous capabilities of fully supporting all flavors of KML. Anything is possible. To support everything in all KML flavors, you end up writing a browser, so expensive even Microsoft is giving up on Edge and turning to using Chrome as a base.
The question is whether that is a higher priority than spending the same effort creating features and capabilities more useful in GIS work. Maybe some very simple things, like references to other .kml files, might be worth doing while other things, like allowing arbitrary HTML and scripting, not. But in all cases it's that priority that should be stated.
I don't have anything against pulling data from the web. I think that's a great idea and it's good Manifold does that with so many web-based data sources (all those many web server standards) both with web servers and also with things like CSV files pulled over the web.
But I think the way to do that with web based KML is to do what's done with web based CSV: allow entering a URL to the file in the Source box in the New Data Source dialog. As with CSV, when somebody puts a URL into that box they know they're connecting to an external file.
Do that and then they could refresh when desired. I'd also consider adding a refresh option, to refresh every given interval, only when the project is opened, etc.
But if the objective is spatial data, I don't think it's good to automatically execute scripts and so on inside of KML files.