Yes, we need "Why POSIX made the Editor Grumpy". It could be a nice long series - with lots of guest editors probably.
But telldir/seekdir isn't something that POSIX got wrong. Maybe the cookie size (32bit) is a bit small, but that is as easy to overcome as the Y2K038 bug.
Either you require readdir to return all the entries in a directory in one hit, or you need a stable pointer into the directory so you can ask for the 'next' chunk.
The stable pointer doesn't *have* to be exposed to user-space, but if you are going to have any hope of supporting a network filesystem like NFS, then it has to be exposed to the network protocol, so it has to exist.
It isn't hard to design a directory layout which allows stable indexes - it just requires a bit of fore-thought.
It *is* hard to synthesis such pointers from a union of two directories as you cannot predict or control the pointers you get from each. However it is possible to create a stable solution.
Given that the current union-mount proposal requires "white-out" objects to be created in the on-top filessytem to make objects from the below filesystem disappear, it would not be unreasonable to instead require 'white-in' objects which make objects from the below filesystem appear.
This would require a 'copy-up' of the directory when it is read (though more typically, when the directory is changed) which is a bit more harsh than the 'copy-up' that is required of files on e.g. a chmod. But it would give reliable semantics and in many real cases would not be a real burden.
To be a little more explicit: The common case with union mount is (I expect) that you union-mount an empty filesystem on top of a read-only filesystem, and then make changes. Each time you make changes in a new directory you need would to copy-up that directory and all parents that have not yet been copied-up. The copy-up involves creating a white-in object in the top directory for each object in the bottom. (It is a little more complicated than white-out as you want to store the 'DT_*' type of the underlying object). Then further changes simply happen to the top level directory.
A readdir simply uses the top-level directory.
Any lookup which hits a white-in object (or name) continues the lookup in the underlying filesystem.
(unfortunately the margin is too small to contain my elegant implementation....)