How about the following limitation?
- Implicit conversions no longer provide extension methods; they can now only trigger based on expected result types
- If you want extension methods, use the explicit extension method syntax
Other than that, I think implicit scope is fine as is: companion object scope is great when it can be used since those will be picked up automatically without imports, while “orphan” implicit constructors defined outside companion objects are occasionally necessary for integrating independent libraries. Both have their place, though companion-object implicits should be preferred where possible.
While not as drastic a change as “getting rid of implicits conversions” entirely, this would be a conservative step in making implicit conversions less powerful and error-prone. This change would explicitly split out “implicit constructors” (or “magnet pattern”) and “extension methods” into two orthogonal use cases. Given the popularity of the new dedicated “extension methods” language feature, I think such a split would not be too controversial.
For people who want both together they can still get it by asking for both (perhaps with a bit of boilerplate), but by default people would reach for the specific tool they need. In most cases, this would be strictly less powerful than the status quo of using “implicit conversions” to serve all purposes.