And what if (for example) GoScintilla has a memory leak in one of it's procedures... The author fixes this leak without modifying the Procedure names, or functionality... Rather than just you downloading a new version, placing it into your code base, it would also be my responsibility to update my distribution containing the new, bug-fixed version.
Yes, that's one of the options. The one guaranteeing your code will work as it supposed to do (because you checked it).
The other one is to left anyone to do to as he please and hope all works well, if they have still access to the same include you are using, and without unexpected side effects.
Also, not every author would be happy about me including their source code in my distribution. Especially if a restrictive license is applied to the work.
That's why I said: "But in any case, or if you can't for some reason ...".
In that case there is no way out.
Now, the framework which I am currently working on may contain up to 50+ include files, that'll be contained within a subdirectory... There will be a lot of updates to it, which will not affect the currently existing files (unless for bug-fixes), and users may not want to have to go through the work of copying the new files to every project they are referencing it in.
I'm doing the same. I don't see the need to duplicate that for every user-project, as I said.
But now I understand you are talking about the need of distributing something not self-contained, possibly needing more than one third-party include and every single one of these can be anywhere on the target disk.
In that case, MULTIPLE different search paths can be useful if you don't have a single, master, root directory under which you keep all your includes (and your project).
Having additional search paths is a tried and tested method which is successful (hence Visual Studio), and the feature would be very useful to those who would want to take advantage of it. You may want to use 'work arounds', but I would personally like the option.
In my case is not a workaround and works well, but in your case it's not applicable. That kind of "sparse" structure is something I try to avoid but I have nothing against your request.