4.1.1 Preserving established declaration rules

Consider what an int n states, reading it right to left.

“An object named ‘n’ of type integer.”

But what is a type here? A type is representation in memory - technically - but a constraint semantically. In the case here the value can only be in certain range and only whole numbers. One can say, the value of a variable is constrained by its type.
In a way, we have been writing constrains for decades, constrains on values. Let’s rephrase the above with that in mind:

“Object named ‘n’, that can have [only] values, belonging to the set of the ‘int’ type.”

Ok, given the above, why should constrains on types be expressed any different?

Consider now Number Num n:

“Object named ‘n’, that can have [only] values, belonging to the set named ‘Num’, ‘Num’ can [only] be a type, belonging to the set of the ‘Number’ concept.”

As You can see, we are not inventing anything, we are just_ recursively applying a constraint,_ right to left, as we always have!
In the case of constrained auto, we are simply omitting the name, effectively stating, we don’t needed it - Number auto n.

Sidenote, there are proposals, advertising the possibility to be able to omit the variable name also. Using the syntax from P1110R0, we can have fully unnamed, fully unconstrained declaration - auto __ - alongside the fully named, fully constrained declaration we just described, or any combination b/w named/unnamed variable, named/unnamed type, constrained/unconstrained type and constrained/unconstrained variable.

4.1.2 Preserving established relationship b/w auto and a type name

It must be pointed out, auto already stands-in for an omitted type! At the moment in all, but one case (structured bindings), if we replace auto with a type we end up with a valid declaration, the meaning might change, but the declaration will be valid. This means the user already associates auto with a “type stand-in”, even if the declaration meaning changes by the substituting one with the other.
There is no reason not to continue this relationship - if the user sees an auto, he should be able to write a type name in its place. What this name represents will be new (a name introduction), but the context is also new; besides we don’t stride too much away from the established usage.

4.1.3 It is actually the tersest form possible ever!

auto copy(InputIterator auto begin, decltype(begin) end, OutputIterator auto out) -> decltype(out);
template<InputIterator It, OutputIterator OIt> copy(It begin, It end, OIt out) -> OIt; 
auto copy(InputIterator It begin, It end, OutputIterator OIt out) -> OIt;  //< proposed

// Even compared to the original, concepts-instead-of-types syntax!
auto copy(InputIterator being, decltype(begin) end, OutputIterator out) -> decltype(out); 

4.1.4 “OK, but still two declarations in one expression, this is madness!”

Type and variable declaration have always been in C++, inherited from C. And they still have their uses.

void process(class C& c);
//...
void something()
{
  process(get_c());
}
// ...
class C {...};
// ...
void process(C& c)
{
  // definition
}

also

class C
{
  // ...
private:
  const class Helper* sos() const; 
};

As shown, two-in-one declaration is nothing new and although the above expressions can be written separately, this does not change the fact, an extremely similar syntax, with de facto the same meaning (introduce a typename inline) is already here - we just reinvent it for the new era.

In contrast to the elaborate type specifier the declaration is limited to the current function declaration, as-if the type was declared as template parameter!

By this point it should be evident, enabling type name introduction in the proposed way, not only does not introduce new constructs and concepts, but serve to reinforce established ones.