>Whether you want to call it a sound server or not is irrelevant since it fulfilled the same role and had the same features as other sound servers of the era.

This is not semantics from me, you are trying to say the phrase "sound server" doesn't mean anything, or it actually means "servers but also plugins". No, that's not true. It has specific meaning. You are limited as to what you can do in an alsa plugin. It is not the same as having a daemon running.

If you are saying from the perspective of the ALSA API, the interface is the same as dmix, that is true. Those sound servers have just provided their own pcm. If you want to use this to say "I don't care as an application developer if it's a plugin or a sound server" then that should also show you that the approach of dmix is not all that great or important.

>The point was that Pipewire didn't follow this Pulseaudio-specific design

And I will say again that what Wim actually did was intentionally choose a design that could easily be used to implement a Pulseaudio-specific design on top of it. That is why pipewire-pulse is able to work. You can ask him about this yourself, I would rather not go back and forth with this hearsay.

>Unless you are going to claim that gstreamer itself is "most programs"

You have missed the point of that part though. Transitively it may very well be "most programs" if you use a lot of media apps, because those apps will use gstreamer which then uses pulseaudio underneath. Anyway I think it is pointless for you and I to keep harping on this one person's opinion, because that's all it is. An opinion on a blog. This is really not worth getting worked up over.

>Everyone (including Lennart) _still_ recommends you target the ALSA API directly.

He can recommend that all he wants. As you have found out, in open source that doesn't stop people from using the API. They will use whatever they want, for better or worse, irrespective of whether it will complicate the mess or not. Actually I would say all of open source is just a big complicated mess that will never reduce as long as it keeps growing.

>If only stuff like gst had used the PA API, PW could have just shipped a gst module

They did do that, this is not enough to call it a day though because it would not ensure binary compatibility with old gstreamer builds that don't have the new module. Also that is only one library, it doesn't count all the other libraries that fall underneath this category that may not support modules. The suggestions you are making are either not realistic or are hypotheticals based on hindsight. Of course, had anyone known all these issues years ago, they might have made OSS the perfect API at exactly the right time and then there would be no fragmentation. But the ship has sailed on that.