implicit vs given in a half-migrated Scala 3 file

I only know this from Kotlin, which made the same bargain with Java, and there the bill arrives as platform types. A String coming back from a Java method shows up as String! in error messages, which is the compiler's polite way of saying it has no idea. Treat it as non-null and the check moves to run time. If you're lucky that's a tidy NullPointerException right at the assignment, if you aren't it's three calls later. Annotate the Java side for nullability and Kotlin believes you. Which is fair. Still two mental models, but at least the compiler admits there are two.

Keeping the old form compiling is fine as long as a newcomer meets the new rules first. If new files start out with given and using, and the old style only survives where nobody has migrated yet, the first thing a beginner copies is the new form and the old one reads as legacy.

Part of the two-models feeling is smaller than it looks. Resolution is one pool. An implicit val can fill a using parameter, and summon finds it just as it finds a given, so the search itself doesn't care which spelling defined the value.

Where the half-migrated file really bites is imports. import foo.* still brings in the old-style implicits, because they're ordinary members, but it skips the givens. Move one instance in foo from implicit val to given, leave the caller alone, and the caller stops finding it. That at least fails to compile. Worse is when it picks up a different candidate from somewhere else in scope and everything compiles. The fix is import foo.{*, given}, and that import line is the first thing I check when a value seems to come from nowhere.