3.1 Dichotomy

First major problem with the status quo is the fact, we have two static polymorphism systems. As mentioned in Motivation, the user can choose b/w having it easy, but limited or having it powerful, but hard (developing effort, code changes, learning ramp). Because the second option does all the first one does, it is “better” and “more correct”, but with no natural progression (or discoverability!) b/w the two options there always be a pain-point in a project: “Is it worth it?”. This rises the question:
Is a project doing “simple templates” generic programming an “unprofessional” one?
(Assuming limitations in user experience like the need to use inheritance/wrapping, etc.)

This is an important question.
If the answer is YES, then the simple method is just for people who “don’t get it” or “don’t want to put the effort” (yet?).
If NO, then we have two systems intensionally for reasons like “legacy” and/or “simpler tasks” or something else, we convince ourselves into.

Either way, it is not a great place to be. In practice, most programmers will continue to use simple, “turn on templates” method and the “right” method will be limited to few “library writers”, who really have to cover all cases, and really want it to be easy for the end users.

There is also the question of teachability, including for people migrating from other languages.
How exactly one writes (static) generic code in C++ in the end? How can one port a library from another language, what are the language tools? Can an expert in, say, signal processing write good-to-great generic library, without being a C++ expert as well? And even if he/she is a C++ expert, will he/she choose “the right” way, considering barrier of entry for contributions?

3.2 Explicit type mapping in the wrong place

Second serious problem is that this new method puts explicit re-mapping calls (of entities to types’s implementation) inside of the function body. This is radically different then most other generic programming, C++ or not. The other two most post popular methods, templates and dynamic polymorphism, both move this mapping outside of the function, delegating it to the class itself in one for or another.
The only other generic method that forces body code change for the purpose of remapping calls is “variant”, but that code change comes naturally as the author wants exactly that, to remove the mapping from the outside world, doing it manually inside the function instead. And even then, the author can use the objects as usual by manually selecting the type first:

void silly(variant<A,S,D> t)
{
  // ...
  using V = variant<A,S,D>;
  variant_alternative_t<1, V>::type; // remap back to S 
  get<1>(t).do_this();               // remap back again to S 
  get<1>(t).do_that();               // remap back yet again to S 
}

void silly(variant<A,S,D> s)
{
  // ...
  auto s = get<1>(t);  // remap just once to S 
  decltype(s)::type; 
  s.do_this();              
  s.do_that();              
}

In modern generic programming, however, we are forced to do the mapping on each call:

template<S_like T>
void odd(T t)
{
  // ...
  Sness::traits<T>::type; // remap back to S 
  Sness::do_this(t);      // remap back again to S 
  Sness::do_that(t);      // remap back yet again to S 
}

What makes things infinitely worse is the fact, the mapping itself must first be created by the author! Literally, a library is needed for what the type does. This is quite different from all other generic programming, including in other languages, and different not in a good way. Having a pice of code that needs an accompanying library and then littering it with explicit calls to that machinery, replacing essentially trivial expressions like method calls, is a bad proposition. One will do it only if really has to.

This is not to say, the remapping itself is a bad thing! Quite the contrary, exactly this remapping is what makes the modern generic programming powerful, compared to the basic template. How (requiring a separate library) and where (invoked via explicit call each time, from inside the function) is unattractive, if not weird:

From the point of the user, the template argument is the customization point of the function/class. As far as the user is concerned, what the function/class does is customized on the type. Period. What we however mean behind “customization point” is an extra entity, which sits b/w the concrete type and the actual code. Combining these two, it turns out, we have customization point of a customization point! Seeing it from that perspective, it is no wonder, most people will not be bothered with the second layer of indirection.

3.3 Syntax

Verbosity

By lacking singular mapping point for the entire function body people are forced to use explicit full paths into the library objects on each and every access to the objects. Contrasted to all the code elsewhere, generic and not, C++ or not, this is very jarring.

Forced free function call

Not all actions translate well to free functions calls. For some the fit is quite good if not perfect, for example std::swap, execution::connect², but for some, arguably most, moving to free function is completely unnatural (e.g. all getters and setters like execution::get_scheduler, execution::set_value, etc). Having properties of a type not being expressed as members will never sit well, especially when we have the same ones already as members like get_allocator.

Overall the syntax is “atypical” at best and quite certainly not something the vast majority of programmers (C++ or otherwise) will willingly opt for.