If you have something like CloudFront in front of your site you can actually make a subdirectory be served from a different origin. To the browser they actually come from the same "place", its just AWS is sitting in the middle. I'm sure its the same with Fastly (Don't use that feature as their shared ssl offering is like and extra $100 p/m) and with cloudflare.
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.
Don't get me wrong, but this way of serving content has been common since, well, apache 1.2 days and mod_proxy ReverseProxy: CDNs did not bring anything new in that respect.
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).
Sure, and a service that is able to scale much better, has a fatter pipe, allows configuration through a web UI...
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.
