I do have some appreciation for how badly it would break a lot of the web applications though, but it seems like it might work.
GDPR only safeguards your data from the honest. What we need is a technological solution.
Users or extension authors can't do much other than blocking those scripts or restricting what the whole page can do because it's difficult to attribute actions to a specific script.
When things don’t work I either disable it for the site or click away. Sometimes I fiddle with it out of curiosity to see what the site relies on.
As a side effect it gives me a sense of what sites are professionally built and which are not.
EDIT: What I mean is example.com/api/hello could hit your back end, but example.com/js/script.js hits S3 (or another static hosting service) instead of hitting your real origin.
So even though to the browser it would appear that /js/script.js is coming from example.com it could actually be coming from anywhere else.
BUT the cookie origin would take over. So if script.js was a tracker. the cookie it set on the browser would be example.com and not "AnotherSite.com" which had the same tracking script. But if the script can make the same fingerprint from both domains then that's not so much of and issue. But thats going back to other methods of fingerprinting.
Basically, you are confusing some terminology and not really making any point: in your example, there is only one origin, that of example.com. Yes, servers can forward any data they wish to other web sites (like AnotherSite.com).
What is the point?
But in this context, how does this matter? "Origin" is a client/browser side concept, and however you serve your website internally, it appears as one web site. Basically, I replied to a comment bringing CDNs into discussion where they are totally irrelevant.
Origin checks can't protect you against servers forwarding your data to a privacy-invading site (eg Google), and a server can do that simply by being a reverse proxy to another site.