The C / UN*X convention for specifying directories to be searched for header files, libraries, and so on.
There's no syntax for "this directory and all its subdirectories" in this world.
DG's AOS did it right, if memory serves, back in the days of 16-bit minicomputers. There was a wildcard for "all subdirectories" - from fading memory (confirmed by a PDF of the manual), it was the gridlet (#). Meaning was somewhat context-dependent, but I seem to recall that, when specifying a list of files, foo:bar:# would get all files under foo:bar, and when specifying a search path, it would get all subdirectories of foo:bar.
(This is a vague recollection; I haven't touched AOS since the 1990s, and don't seem to have brought the manuals home with me.)
I seem to recall that Knuth's TeX also has some convention for this sort of thing, and a library to implement it.
In the mess I'm staring at just now, such a convention wouldn't be all that helpful, owing to the unfriendly organization of the source tree, but I keep coming across situations where there's a huge list of -I$PROJECT/include -I$PROJECT/include/sys -I$PROJECT/include/drivers and so on.
I also have yet another rant on IDEs coming on, but that's for another day.
Afterthought: AOS got a lot of things amazingly right, for running on such limited hardware. The CLI didn't have all the bells and whistles of, say, bash, but it was really easy to do some common things that remain awkward under *NIX-style shells. Maybe (IMCFT) I should write a sort of hybrid CLI, with the AOS-style nice features massaged to fit the *NIX environment, and of course all the really-commonly-used shell features included. Not happening this year, though.
...And maybe I should try implementing an Eclipse in an FPGA? A Nova 1200 would be trivially easy; the Eclipse architecture involved sequencing and microcode and such, but still fit in a 15" square board with 1970s technology, so cramming the whole thing including a couple of I/O controllers into a Spartan 6 ought to work. But I don't think I have any AOS backup tapes lying around (and I certainly don't have a 9-track, 1600 BPI tape drive to read them on anyway), so maybe there's not much point.