Extracted from #66490 (comment):

There seems to be some consensus (multiple people think it, so far nobody has disagreed) that the zlib.static output being a special case vs pretty much all other packages is confusing and annoying.

Other packages can enable .a files in batch in a consistent way by e.g. setting dontDisableStatic for all of them, but it doesn't work with zlib, and until #66490 having .so and .a in one output as almost all other packages make possible, was impossible.

The split .static output also breaks pkg-config, because the zlib.pc file generated as part of the main output does not include the directory of the .static output in which the .a file is, resulting in the need to manually pass -lz when wanting to link statically in lots of places. (This may be fixable by rewriting zlib's .pc file, but it seems better to just make zlib a normal package where .a files appear in the .pc just like for all other nixpkgs packages.)

Quoting @matthewbauer, with the order of his sentences slightly rearranged for clarity:

splitStaticOutput [added in #66490] definitely makes things clearer, although for the same reasons you describe in .pc; pkg-config assumes that all of your libraries are in the same directory. I was hoping we could eventually phase those out altogether. There are a few things that rely on this output existing though.

Should we find all uses of zlib.static and get rid of it / deprecate it?

Does anything speak against this plan?