If I understand correctly, this proposal goes into this proposal's direction (#86), although it frames it differently.
Important: Naming is entirely free to choose. Alternative “associated sets extension” would also be acceptable.

First Party Sets GDPR Proposal

Problem statement:

The original proposal to structure first-party sets by entity ownership has been changed in the current draft for FPS. There are now different sub-sets. For publishers who have the same ownership (according to GDPR, also same controller) of several domains, there is now an associated set. These sets are limited to three. In contrast to the previous proposal, domains that do not have the same ownership (different controllers according to GDPR) can also be merged into one FPS in associated sets.

Example 1:
website-a.com (company A) website-b.com (company B) website-c.com (company C) is allowed under FPS.
Example 2:
website-a.com (company A) website-b.com (company A) website-c.com (company A) website-d.com (Company A) is NOT allowed under FPS - maximum three.

In example 2, it would be the same controller under GDPR. It's the same data under the same entity and the same legal framework (GDPR). So if the data collection with different domains but with the same controllership is a reliable consent of the specific controller regulated by GDPR law and authorities, it should not be regulated by the browser.
Interestingly, in the other three proposed subsets beside “associated subset”, there are also ownership requirements: top-level domain differences, domains on the public-suffix list, and service subsets with CDN domains. So here, ownership is also checked. But this ownership check is supposed to be based on a public submission process, domain access, and other processes that certainly do not stand up to a KYC check (Know your customer ). However, many reliable standard processes today in the industry are based on this idea.

In summary, subsets are proposed that do not take GDPR into account on the one hand (associated) and, at the same time, others that are based on ownership via processes that are easy to abuse and are not subject to audited control.

Idea: GDPR subsets

A new GDPR subset relies on reliable proof of ownership and, therefore, on the same controllership. But on the other hand, let authorities decide and enforce what reliable consent is to bind data from different domains altogether for the same data controller entity.
Use an independent European Trustee Org (like SSL Cert companies before) to make the proof of ownership process, which must certify in dedicated periods ownership. This process has to be paid for by the demanding parties (publishers) and should give the org a business case to be reliant and long-term steady. There should be trust in this Trustee Org, so it must be carefully built or pitched by the industry and balanced regarding control by browsers, publishers, and other industry stakeholders.

Known Critics:

There are known critics of the SSL Cert process.
In financial and other business industries, the whole process of KYC is built on proof processes of ownership. So perhaps an SSL Cert process is not the right technical idea. Still, with technology, there should be a way to make trusted industry processes inside a regulated environment like the EEA or EU. In case of abuse, there could be a penalty process to revoke proof of ownership by the Trustee Org as well.
In any case such a process has to continously be improved and developed, as abuse can't be ruled out in any case. Additionally - to mitigate eventual abuse - there can be strong enforcement be the Trustee (ownership abuse) or Authorities (consent abuse)