I think Scala will always suffer from its choice to make implicits so fundamental. Whether abused or not they impede compiler efficiency and complicate code. Implicits were the main reason I dropped Scala a few years ago.
All languages have their own "implicits" - just not as a proper language concept, but for "special cases". The problem is, that while it gives developers are more stable/clear framework to work with, it also limits the development of the language itself.
If you look at Scala, implicits could be used to model typeclasses from haskell and method-syntax-extension. Other languages such as Kotlin have a dedicated language feature for that. Scala never needed that.
However, this power also ask for responsible usage of course. That is a drawback that can't be denied.
To be fair those are powered by two different mechanisms (implicit arguments and implicit conversions) that just so happened to share the same keyword name but are semantically quite different (and have been broken up in Scala 3).
But your overall point is well-taken.
You can call it like that, but in the end it is the same language feature: describing things in a scope as implicit and having the compiler resolve them by certain rules.
What happened in Scala 3 is just that they were named different to make clear when things get defined and when they get used - one without the other is useless though, hence to me it is the same concept or language feature.
Implicit arguments... man I go back and forth on that so much. On the one hand every crazy tower of abstraction that grinds the compiler to a halt in Scala inevitably begins with implicit arguments and you can have a really rough time with them if your IDE doesn't support looking up implicit arguments. On the other hand, if you want ad-hoc polymorphism, implicit arguments are really useful, often far more so than inheritance.
My usual take on this is that you probably don't need ad-hoc polymorphism most of the time, which is my way of wriggling out of the dilemma.
For statically typed languages, implicit arguments (in some form or another) are really great at getting statically checked ad-hoc polymorphism.
But even in dynamically typed languages such as Clojure, ad-hoc polymorphism mechanisms bottom out at some form of implicitness at runtime. I assume you're referring to multimethods here (which generalize protocols, whose very existence is a performance hack akin to atoms vs volatile, so I'll focus just on multimethods)?
The entire lookup system based off of defmulti is really just the same thing as Scala's implicit system just at runtime rather than compile time, but even harder to understand IMO because it can change wildly at runtime. The same "spooky action at a distance" problems can result here.
The reason this isn't an issue in Clojure is that multimethods are very rarely used and instead a lot of code just specializes on vectors or maps (again going back to my point that you usually don't need ad-hoc polymorphism).
Thankfully it won't. Scala 3 deconstructs implicits and discourages (or outright discards) the bad parts: http://dotty.epfl.ch/docs/reference/contextual/motivation.ht...
"Implicits" are useful for the Type class pattern and is available in Scala 3 with an improved syntax.
"Implicits" for implicit conversions is an ugly hack that should be avoided as much as possible and Scala 3 restricts it.
"Implicits" for extension methods is a clever hack, and Scala 3 provides a dedicated syntax for defining extension methods.