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