Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which return a Stream).
It then turned out that they could be used to simulate extension methods, which is probably the main use case for implicit classes in Scala2.
And implicit parameters were probably just the result of trying to make type classes modular.
The CanBuildFrom approach came later than implicit parameters (https://stackoverflow.com/questions/1722726/is-the-scala-2-8...).
"Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent"
So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.
The desire to return the same type of collection lead to overall slow performance; it turned out it's a design dead-end that Scala is still suffering from.
It should simply have been abolished and replaced, instead of applying some minimal fixes in 2.13 that preserved the wrong design choices.