> AFAICT [`case's] "simplicity" is just the fact
> that it's a lot more restrictive, so you can
> get the same simplicity by resisting the
> urge to use the extra features of `pcase`,
> without having to learn another syntax.

That's what you've been claiming, and what I've
been requesting examples of.  Please show, for
the "restrictive" use case that `case' fulfills,
corresponding examples of `case' and `pcase'
that demonstrate, in your eyes, that `pcase' is
simpler (or even as simple).

Examples head-to-head for that simple case will
show the differences.  So far, you've given only
non-examples of non-`case' syntax, to show the
misunderstanding you've encountered.  I've shown
some `case' examples.  Please show equivalent,
but in-your-eyes simpler, `pcase' ones.  Or show
other examples for the same simple use-case.

It's not about comparing/contrasting `case' and
`pcase' in general.  It's about the particular
use case that `case' was designed to address.
How does `pcase' excel there by being simpler?

I haven't argued that `pcase' should go away.
I argue that `case' is better for what it does:
that simple, common, "restrictive" use case.
Please show us otherwise.

But more generally, and perhaps less as a matter
of preference or personal taste, I argue that
it's good to offer _both_ `pcase' and `case' as
part of Emacs, i.e., to treat `case' the way we
treat `cond', `if', `when', ... and `pcase'.

I'm not surprised that some Emacs users have
incorrectly thought that the keylists and keys
get evaluated, and so have mistakenly quoted
them - because, as I just discovered and pointed
out, the Emacs _doc doesn't say_ that they're
not evaluated.

How is a user to know whether something gets
evaluated or not by a macro, if the doc doesn't
speak to that?  Do we expect a user discovering
a control structure to immediately macroexpand
guess uses to see what the expansions give?  Or
to analyze the macro's definition?

It's perfectly understandable that someone
might just assume evaluation everywhere,
especially since the doc here keeps repeating
"evaluates".  The only parts for which it
doesn't say anything about evaluation are the
parts it really needs to say something about:
keys aren't evaluated.

On the other hand, the Common Lisp doc points
out clearly (and even emphasizes) that keys
aren't evaluated.

That doc difference alone could explain why
you've see some Elisp users confused and
mistaken, and why I've never seen that among
CL users (and you apparently haven't either).
Maybe the problem you've noticed was just
caused by our poor `cl-case' doc.

How about we fix the doc and also raise `case'
to first-class citizenship along with its
compatriots?
___

You haven't responded to specific points I've
made - that's your right.  But could you at
least please speak to this, which to me seems
to be a bug in the `pcase' node in the Elisp
manual, where it compares `pcase' and `cl-case':

 It shows a `pcase' example which starts with
 this: (pcase (get-return-code x) ...
 
  "With 'cl-case', you would need to explicitly
   declare a local variable 'code' to hold the
   return value of 'get-return-code'."

 Huh? Does that mean you need to use a variable
 as the first arg to `cl-case'?  If so, that's
 not right.
 
 (defun get-return-code (arg)
   (if (< arg 42) 'success 'failure))
 
 (let ((x  13))
   (cl-case (get-return-code x)
     (success (message "Done!"))
     (t       (message "Unknown!"))))
 
  ==> Done!
 
 And with x bound to 56, ==> Unknown!
 
 We didn't "declare a local variable ... to
 hold the return value of `get-return-code'."
 ...
 It's the value returned from evaluating the
 sexp (get-return-code x) that `cl-case' tries
 to match (using `eql') against symbol `success'.
 `cl-case' doesn't need its first arg to be a
 "local variable".
 
 Let me know what I'm missing here.