Yeah this would be great. I started working on adding support for <hook>.d/* in addition to <hook> a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished.
There was also a disagreement about what the semantics should be, e.g pre-receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whether they can run in parallel.
The bit that stuck from those patches was being able to configure the the core.hooksPath variable to a hook path, which sometimes can with some stretching fulfill some of the use-cases, but most users end up with a meta-hook runner of some sort.
The glob() function is sorted consistently on all platforms. It's mandated by POSIX[1], and from the OSX docs I could find[2] sorted unless you specify the POSIX GLOB_NOSORT flag, as on other platforms.
In any case, even if glob() wasn't portable it's easy to provide an API compatibility layer that's just readdir() + qsort(). That part would be trivial, and might perhaps be needed due to collation issues in the sort.
Doing it in parallel (preferably in a random order) isn't just an optimization, but would ensure that there isn't an implicit dependency on whatever iterative interface we'd first ship with.
