When is a construct that is not required by the compiler or Pkg included in Base? What criteria are used to decide if a PR adding such functionality should be merged? Are these criteria documented?
For example, I’m thinking of a pull request that proposes to add LogRange, a useful but unessential type to Base.
Generally if it can go into an independent package, it should probably go there first. If that package becomes so widely used and perhaps better maintained within Base, then perhaps we should include it.
The linked pr could certainly go in an independent package, yet none of the twelve participants in that conversation (including all three of Jeff, Stefan, and Viral) have ever brought up the idea.
Functions are regularly added to Base that could as well live in independent packages according to these criteria. Recent 1.9 inclusions are stack and Iterators.flatmap, earlier 1.8 were eachsplit and allequal. I think there are other considerations, mainly the core developers’ judgement of how commonly used these functions would be.
As far as I’ve seen, there really is no policy other than “was the triage call able to agree it was a good idea?”.
Clearly this one is a good idea 
People like to say “package first”, but it’s not so clear that this is how it actually goes for small features that have one fairly obvious design. Can anyone name some packages which became “so widely used” in this sense, and were then added?
The much-discussed JuliennedArrays seems to have 1 dependent… everyone liked the idea but nobody wanted a dependency? Julia 1.9 will instead have Slices built-in.
For sure there are dozens of roll-your-own allequal implementations for local use – easy to be slow & have bugs, not worth a package. Likewise I think it’s unlikely anyone would depend on a package just for Iterators.flatmap.
On logrange, maybe worth noting that numpy has not one but two, logspace and geomspace. Julia used to have one. (And every plotting package must have one somewhere.) Which I read as understanding that such an object is a natural counterpart to linear ranges. But Julia’s old one had the much-less-useful constructor, the one which saves you typing 10 .^ (range) not the one which saves you any thinking, and hence was removed.
Never heard of that package before. If that’s about efficiently splitting/combining array dimensions, SplitApplyCombine has that and has much more dependents. Other packages also use/define combinedims/splitdims-like functions, so in a sense this functionality was already implemented in popular packages - just not in a single commonly-used one.
Maybe, this can be the criteria for inclusion into Base?
Would also fit the “implemented in many packages” condition.