The proposal in question:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1371r2.pdf

Hello, I would like to share my core concerns with the current PM proposal.

*1. I don't see the need for the dereference pattern.*

This pattern introduces (extreme) noise and unfamiliar (to put it mildly)
look into the code.

It is not needed, because
A) in PM we can always have implicit test and dereference
B) the user can use a extractor for the *! case

*2. Bindings are mutable.*

The design envisions mutability, similar to a for-loop - immutable only if
the object is immutable, but I don't believe this is practical and good
enough.

In practice, in contrast to a for-loop,
 - PM can grow very large, with multiple bindings, multiple lines and
multiple bindings per line. This would mean, if just one has to be mutable,
ALL will have to be.
 - Second, because of pointers to sub objects, vast portion of bindings
will *not* be immutable, unless we invent special rules for PM alone.

Bindings should be *immutable *with a syntax (&) to create mutable one.

*3. The decision to introduce `let` is not well motivated.*

In C++, auto is used to declare new variables and has storge implications.
> Our decision is to use let syntax that will avoid confusion over possible
> storage implications for the newly introduced identifiers and highlight the
> fact that it creates new __binding__s, rather than __variable__s


However structured *bindings *already introduce bindings to the language
with the `auto` syntax.
Further, the storage question will be present with the `let` kw as well -
people will* still* ask "does the 'let' create a copy" because there is no
& syntax in sight. They will ALSO question "what is the difference b/w
`auto` in structured bindings and `let`".
Introducing a new kw will create as much problems/questions as it solves.

Lastly, AFAIK, know other language has different kw inside and outside PM
for identifier introduction!

*4. The lack of logical operators is a severe limitation, which I don't
believe is justified.*

 Considering we have *two* ways to write logical operators, we could
reserve one for combining patterns and let the other for expressions

inspect(v) {
 (a || b) or 5 => ...
    ^^^ expression OR
           ^^^ pattern OR
}

Yes, this will complicate parsing (inside `inspect` rules will change a
bit) and
Yes, the user is forced into syntax style (and new rules who to read code),
but both are well worth the gain.
Using "marchers" for such basic tasks* will make C++ look bad*.

These are the core issues I wanted to share. I have some other issues, but
they are more of an opinion.
Thank You