I tend to live-in and build my own ecosystem anyway, so I haven't used any of these libraries. But I've looked at them... and I think "containers" goes for a more self-contained-module approach like you were looking for with string split... Looking at it now I see the 'sep' function does use a bit from within the CCParse module it's defined in -- but that module is built on the parser combinators it defines. I think the individual module can be taken as-is, or parts of it, without hunting down other module dependencies.
This doesn't address the core problem you raise. Haven't thought much about it, as I'm one of the few(?) who is okay with the sparse standard library. For games, it's pretty much tradition that you write your own stdlib anyway -- things end up being different... stressing particular use-cases or performance characteristics. And, overall, not suitable for general purposes. DBuenzli has contributed a lot which is actually quite game-relevant, and his style is standalone modules. You could consider his collection of "libraries" (modules really) as a library in it's own right. :) Maybe that style is a good model? Come to think of it, the OCaml stdlib modules are generally quite standalone, aside from Pervasives, aren't they? So maybe ccube-containers and dbuenzli's style are really very OCaml-ish.
My own stuff, by comparison, is horribly layered with dependencies. I generated a dot-graph showing dependencies and nearly everything depends on another module, often which depend on others. I don't like redundant code, and this is the result... but it makes for modules which cannot be easily teased apart. Probably similar to Batteries-style.
-Tony