bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring

[Drew Adams]

> >> The root of this is the old discussion of how strictly cl-lib should
> >> follow the Common Lisp originals.  We will not pacify this discussion.
> >> I think we found a good compromise in most cases, even when it is not
> >> the optimum for everyone.
> >
> > FWIW.
> >
> > Dunno which part(s) of the people I fall in, but my
> > opinion is that we should have separated, and we
> > still should try to separate (1) actual Common Lisp
> > emulation/reproduction/whatever-you-want-to-call-it,
> > which should be quite faithful to the standard, from
> > (2) non-CL constructs (functions, variables, macros,
> > special forms) that might seem a bit CL-like or that
> > might share some of the underlying implementation
> > with some of #1.
> 
> Agree 100&, but that ship seems to have saild.

I think it's (at least at this point) about deciding
and stating the intention.  At first there we none
or few non-CL things offered in the cl-*.el code.
Then a very few more.  Then a bunch more.  If no
intention is declared that just adding non-CL stuff
almost/seemingly willy-nilly to cl-*.el is OK, such
addition might well be increasingly likely.

IOW, let's not hope for perfect, and give up because
things are already imperfect (that ship has sailed).
Instead, why not declare that it's better to not add
non-CL stuff to cl-*.el files, and work to keep it
out.  Not adding more, and declaring that policy, is
at least better than adding more with no such policy.

Just one opinion.  We could improve things a bit here.