On initial read, P1204R0 sounded good and makes sensible arguments for its reasoning that I couldn't argue against at the time. So I figured I'd try it out on an existing project, and hit one detail that's a complete showstopper for me: Prefix lib for includes.

A consequence of library target folders being named libfoo is that #include must also use <libfoo/...>. That's a step too far. #include <> implies it's a public library and thus implies lib - users should not be required to write lib here. It's not <libboost/...> or <libiostream> or really <libanything> - I've never seen prefix lib in public includes, and I don't want to. Installing a package libfoo gives you <foo/...> - it does not and should not give you <libfoo/...>. No other language does anything similar either.

One possible resolution is to have folders at least for target types. Something like libs/ and bins/ so that we can have libs/foo/ leading to #include <foo/>. I realize this would be a potential conflict with headers in bins/foo/ and that the paper has reasons for ""-includes being problematic, but quite frankly any minor risk with ""-style is worth it to avoid prefix <lib/>.

-- Tino Didriksen