Sure. First, what is tracking? The definition of tracking in this case would be something along the lines of being able to correlate two un-authenticated requests to different domains as coming from the user.

It was going to remove or restrict features in the web platform that can be used for both tracking and for important non-tracking tasks, and replace them with features that can't be used for tracking but can be used for achieving those tasks. In some cases it meant making sure that data that could be used for tracking was never received ambiently, but had to be requested explicitly. That's why we have the new mess with User-Agent.

You could not just remove the tracking vectors entirely with no replacement, because then you'd be breaking critical workflows that are actually needed for practical operation of websites. That is why Apple for example included a remote attestement mechanism in Safari when adding features to mask IP addresss. (Though they only permit a few of their favored partners to use that attestment mechanism, and these days are being very quiet about it hoping that nobody remembers they did this.)

So, you want to remove the possiblity of using the web API to do tracking? How do you prevent that? The Privacy Sandbox solution was to give each domain a budget of how much entropy they could extract (this is why e.g. moving from the User-Agent header including data by default to the site having to request it was supposed to make sense). In some cases they were going to remove the feature entirely, but instead have the browser achieve the same effect, and provide a verdict or attestation with so little entropy or so little consistency that it could not be used as an effective tracking vector.

It was a doomed program, but they did have good intents, and never deserved the abuse that was heaped upon them. And I will be dancing a little happy jig on the grave of their "IP protection" feature.