While not disputing in any way the truth of what you're saying: I'm a product manager who leans toward Safari, while the devs I work with use Chrome almost exclusively, and we have an unwritten agreement that when it comes to display/layout issues, I'll double check in Chrome before filing the bug. It's only been Safari-exclusive a handful of times, but that's enough that it's annoying for everyone when it's just me.
I guess the question here has to be: is this actually a bug in Safari? Or is it a bug in Chrome, that people (whether that's your people or third parties) have just been working around in a way that doesn't work in Safari?
And this is a big part of the problem with having Chrome become such a dominant force on the web: people assume that it's correct when Safari displays something differently. And people give instructions and documentation for how to do various things "in HTML/CSS/JS" when they've never tested them in anything other than Chrome, so if Chrome's behavior deviates from the spec there, someone implementing those instructions on Safari will see them fail, and assume incorrectly that it's Safari that's wrong.
Note that I am not saying this is what is happening in any specific case—but because Chrome is so dominant, enough people treat it as the de-facto standard that over time, it becomes a near-inevitability that this will happen in some cases.
I've run into Safari exclusive issues before as well around color transparency, but tbh I'm surprised it comes up that often. Modern IDEs support linters that warn you whenever you are using a CSS feature that isn't supported by all modern browsers. You can even set the year you wanna support (e.g. all major browser versions since 2023). Between that awesome tooling and rapidly improving browser support for web standards, these kinds of issues feel extremely rare.
Except for printing. Printing has and seemingly always will f'n suck. Unfortunately WPT doesn't have a good way of testing for print-related features
