Some issues were technical, but a lot were also politicial/NIH syndrome. There isn’t for example really significant differences between fs2 Task and scalaz7 Task. In any case I don’t really think its constructive to go over the whole cats/scalaz debacle.
It has also failed miserably in a lot of other environments, i.e. have a look at Haskell (3 different string types, which all library authors have to target because its a single string type) or at Scala having ~7 different type of JSON AST’s (i.e. have a look at slick-pg and how many JSON libraries it needs to target GitHub - tminglei/slick-pg: Slick extensions for PostgreSQL)
In Scala its actually an even worse problem because we do dependency management via binaries, and because of the tree your dependencies form its really easy to get into dependency hell due to binary compatibility.
These really aren’t good examples.
The JSON library was included as a demo to test parser combinators, it wasn’t really included as a goal of being a “good JSON library”.
WRT to xml, I am not sure if you are talking about XML literals or the scala xml library. If you are talking about the latter, considering how complicated XML is it actually was quite a good library especially for its time.
In any case it comes down to how critical functionality is, and I believe async primitives (at least if we are dealing with modern programming where this is very common) there should be some basic implementation that is good for general use case usage.
Note that as @jvican has said, this doesn’t prevent community contributions nor does it mean that the SPP doesn’t support a bazaar approach. In any case this is getting a bit off topic and should be discussed in another thread