Unless I made some mistakes, D809 and D842 should resolve this.
Any comment on this is welcome because I don't have a printer so I can't test, but I can install cups & cups-filters and start the service without any error.

This issue is not concerned with whether cups starts (it does, but has the systemd service name org.cups.cupsd.service). The issue is that cups-browsed.service won't start because it requires a service with a name that doesn't exist (cups.service). The same problem has been experienced by users on Ubuntu and Arch, which makes me wonder if it is part of a default config that gets written down and just needs an appropriate filter applied to it at build time to alter. Quick observation of your diffs in both D809 and D842 support this concept - specifically package.yml in D842 seems to copy across the vendor file on line 49 without performing any changes to it. If your package doesn't adjust the name of the cups service from org.cups.cupsd.service to cups.service or adjust the cups-browsed.service file as described above , then the problem I am describing will remain.

If you have a build with your patch deployed, you will be able to test it trivially without a printer using these steps:

# Gain root
sudo -i

# Find out the cups service name referenced
grep -e '^Requires=' /usr/lib64/systemd/system/cups-browsed.service

# Check for the existence of the service (cups.service in this example)
systemctl status cups.service

If the service cannot be found, then systemd will report the service doesn't exist with a message similar to this:

# systemctl status cups.service
● cups.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

@chrisweeksnz in D809 org.cups.cupsd.service is renamed to cups.service, same with the socket name that is also changed.
So actually I did the opposite to what you did (you kept the cups original service name). The reason why I opted for this is because it seems there is an implicit consensus to use "cups.service" and "cups.socket" names. I check quite a few distributions (Ubuntu, Fedora, Gentoo) and all use these names. Cups-filters too and D821 as well.

So when I install both the new package of cups and cups-filter, and I enable/start the services, it works fine. But of course since I cannot do a some tests without a printer, I cannot validate that I haven't missed something... that's why I appreciate all feedback like yours ! ?

Super work! I've let my Solus using work colleagues know that the change is coming and to remove my workaround systemd service when your patch lands.

Thanks for taking the time to comment and explain what is coming :)

I guess this is now fixed, isn't it?

It appears the problem will be fixed when https://dev.solus-project.com/D809 lands, but currently the workaround I described above is still required by myself and others at my company using cups-browsed.

My cups is version: 2.2.3, release: 15 and the problem still exists.

@chrisweeksnz actually there were updates in the meantime and the same names as the one you use in your workaround are applied now.

Oh cool - I didn't noticed. I will remove my workaround locally and get workmates to do the same.

Please close the issue! :)