Here are summarized findings for the new switch expressions and statements for basic types
and their enhanced versions for reference types:

The manual for Java 23 states in 14.11.2 :
    For compatibility reasons, switch statements that are not enhanced switch statements are
    not required to be exhaustive. ...
    If the switch statement is an enhanced switch statement, then it must be exhaustive.
    For switch expressions, it states in 15.28.1: It is a compile-time error if a switch expression is not exhaustive.

So, a general claim for completeness checks would be incorrect. 

An issue that surprised me along the way was that the new switch rules and guards can be used
in old-style case statements that need breaks to not proceed into the next case, but that such
continuations are (necessarily) allowed only into branches that do not include variable
declarations in their switch rules. The language rules to prevent that are a dilly.

And, as Sean already pointed out, a later switch rule must not be dominated (in a
Java-defined sense) by an earlier one.
It was interesting to see the pages of rules that prevent undecidability because of guards and
complication by other interactions, e.g., of unboxing.
 
------------
The following findings from tests are consistent with the manual.

Incompleteness checks switches for Enum types:
	       switch expression: static error message naming the missing case
	       switch statement: static warning, no runtime checks,
	       Fall-Thru semantics for missing cases!

Incompleteness checks for int types:
	       switch expression: static error message asking for "default" case
	       switch statement: NO warning, no runtime checks,
	       Fall-Thru semantics for missing cases!

Incompleteness checks for classes:
	       both switch statements and switch expressions produce a static error message, asking for "default" case

Incompleteness checks for subclasses of sealed classes
	       (where the set of subclasses is final and known)
	       both switch statements and switch expressions check complete coverage
	       (and, in case of error, ask for "default" rather than naming the missing class)

Next actions: Read the existing text with all this in mind....   

Erhard