When introduced by @dabrain34 originally, I'm pretty sure it was intentionally. But I can see your point and agree that it is questionable. One reason to originally go that route was likely the need to include a whole bunch of headers to get anything done with the library and it was more convenient to not have to repeat the ZXing/ prefix everywhere. That changed over the years and will be "completed" once the new writer API (#739) is fully established.

That said, the internal structure of the code base requires a simple #include "Error.h" from within other headers to work.
It seems the #include "..." behavior is generally implementation defined but de-facto standardized (see e.g. here and here). So if you have a compiler that does behave differently, you would need to add ZXing to your include path explicitly.

My current gut feeling says: away with the -I${includedir}/ZXing. Even though that will most likely force some client code to be changed, so this will have to wait for the 3.0 release (which will likely be the next one, anyway).

Can you make that change locally and test if everything still works? E.g. the sample code from the README should compile as is.

I agree with your stance and would prefer indeed to avoid the -I${includedir}/ZXing

I'm also in favor of enforcing namespaced includes (and thus removing the extra include search path), considering how generically some of the installed header files are named.