Yes you're quite right that you can do this when building curl:

  ./configure --disable-ftp

But then you end up with a libcurl that can never support FTP clients. However FTP is still a useful protocol in some circumstances, perhaps very limited these days, but still used. I think that it's better to expose this through a module system reflected into the distribution packages. It makes things much more visible.

> It makes things much more visible.

In what way? Recompiling a few different binaries for various levels of usage (with/without whichever protocols needed) doesn't seem like an arduous task, especially for a distro. And the docs on how to do it from the curl project are very clear and "visible". I'm not sure how any module system would improve on this.

In fact, it seems like it would disimprove purely by virtue of not being idiomatic - compile flags are a familiar and straightforward, well-known approach.

> compile flags

they don't play nicely with os package managers like apt.

Which is another reason why dependencies shouldn't be shared

Your solution is multiple copies of libcurl all over the place, all compiled in different ways, probably different versions, and that's supposed to be more secure and maintainable?

More secure: not more, but equally. More maintainable: infinitely. This is how software is being built today in secure environments anyway, since you need to own the supply chain.

Dependencies are not actually shared that often. Here's a good post about it: https://drewdevault.com/dynlib