The way tracking used to work is:
1. UserA visits foo.com which embeds a script from evil.com. When the script is requested, evil.com sees there's no tracking cookie for this user yet, so it drops one.
2. When evil.com was loaded, the Referer header showed the request was coming from foo.com. EvilCo adds an entry that UserA visited foo.com.
3. UserA now visits bar.com which also embeds a script from evil.com. Now, the tracking cookie from Step 1 already exists, so it's sent with the request to load the script from evil.com.
4. evil.com looks at the Cookie and Referer header, and adds an entry that UserA has visited bar.com.
---
Now, what Firefox and Safari have done, is they've made it impossible for ANY third party to access their cookies while a user is visiting a different site.
I completely understand that evil.com is promoting itself to first-party by routing under evil.foo.com and evil.bar.com, and that allows it to set and receive cookies on those hosts, but that alone isn't enough to break out of the new browser protections.
In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com.
To sync identities across evil.foo.com and evil.bar.com, EvilCo is forced to do some kind of browser fingerprinting, or to rely on the operators of foo.com and bar.com to manually share additional data about the user.
---
Source - I've tried it! Run two separate domains and see if you can get the same unique identifier in cookies on both domains. The only workarounds are OAuth2 and the Storage Access API - both of which require explicit user permission.