>>> (cl-typep '(foo) 'cons-car-foo)
>>> => (invalid-function #<symbol lambda at 125>)
>>>
>>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect.

To fix this problem, `cl-eval-when` would need to do the same kind of
`byte-run-strip-symbol-positions` dance as is done for
`eval-when-compile` and `eval-and-compile`.

But I suggest the patch below instead, which starts by acknowledging
that `cl-eval-when` doesn't actually distinguish if it's used at
top-level (it has an ugly hack which tries to do that, but only for those
`cl-eval-when` nested inside another `cl-eval-when`, which his
extremely rare, and even in those cases it's right only some of the
time).

So the patch throws away the ugly hack and just reduces `cl-eval-when`
to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil.

It might be worthwhile to improve our macro-expansion machinery to let
(compiler-)macros know if they're used at top-level or not, but that's
a larger undertaking and it will be easy to retro-fit it into this macro
if/when we do that.

Comments, objections?


        Stefan