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.

I think it was a mistake to add things to cl-lib.el,
or cl.el, or cl-<anything>.el that is not directly
related to Common Lisp.

I see no reason not to do that.  It shouldn't be any
harder to separate the two than to cram them into
the same library and give everything the prefix `cl-'.

Each time this has come up (some new thingie that's
unrelated to CL that we stick in a `cl-*' file and
give the `cl-' prefix) I've spoken against doing so.
I've never understood why this has been done, and
I've never heard a good argument for doing it.

You think we've found a good compromise in most cases.
My question is why there's any need to compromise.

(This is different from an incomplete or not-so-strong
implementation of some CL thingie.  I'm talking about
our adding functions that are unrelated to CL support.)