The user point of view is quite different.
Documentation is more or less a promise
It is very bad practice to replace a
generic refusal to make a promise with a specific promise that you may
not want to keep.
That is, to keep documentation up-to-date with current behavior? Then
to figure out how to use software one has to dig in its internals,
which is often even harder than writing it from the scratch.
It is just a matter software design quality, a matter of clear idea of
what has to be implemented. So that one can make promises (in
documentation) and keep them. If one does not like this, he should
not write software.
Or, if he wrote it, describe how it behaves currently. And when
redesign it, update the documentation immediately, not as memoirs.
Leaving new behavior undocumented is ok for some short periods of
time. That is what beta for. But when it lasts since 1997-02-27
(as with "this is a trial implementation" phrase in `site-load.el'),
that looks at least strange.
You have said you're not interested in doing this right.
It is again a matter of what is called "right". For the user, it is
primarily correct documentation. It seems to me that current
functionality meets all needs of users like me - provided that it is
documented, so figuring out how to use is reasonably easy.
"Doing its right" as redesigning the behavior is completely different,
and it is really not that interesting for me.