Why architecture matters here
Contextual abstraction matters because it solves a real problem — threading capabilities through code without manual plumbing — that every non-trivial program faces. Consider a JSON library: without type classes, encoding a List[Map[String, User]] means writing encoding logic that knows about lists, maps, strings, and users all at once; with them, the compiler composes the encoder from an encoder-for-User, an encoder-for-Map (given an encoder for its values), and an encoder-for-List (given one for its elements) — each defined once, combined automatically by resolution. The same pattern gives you Ordering, Numeric, Monoid, and the entire functional-programming vocabulary. Contextual abstraction is how Scala expresses 'this works for any type that can do X' with the compiler assembling the machinery, and it is genuinely one of the language's superpowers.
The reason the Scala 3 redesign matters — beyond aesthetics — is that implicits' ambiguity was a correctness and comprehension hazard. Implicit conversions applied silently, turning a type error into a surprising success (a String where an Int was expected, silently converted); implicit parameters and implicit instances shared syntax, so reading implicit x: Foo you couldn't tell if Foo was being required or provided; and resolution failures produced inscrutable errors. Scala 3's separation makes each intent syntactically distinct — using requires, given provides, extension adds methods, and implicit conversions require an explicit opt-in (given Conversion) — so the code is self-documenting and the footguns are holstered.
And the design discipline the new syntax encourages is itself the deep lesson: contextual values should be coherent (one canonical instance per type, so behavior doesn't depend on which import happened to be in scope), discoverable (instances in the companion object where resolution finds them without imports), and unambiguous (priority rules and specificity avoiding 'ambiguous implicits' errors). These aren't syntax features but API-design principles that the syntax makes it natural to follow — the difference between a type-class-based library that feels magical-in-a-good-way and one that feels magical-in-a-cursed-way.
The architecture: every piece explained
Top row: the core mechanism. A given instance declares a contextual value: given Ordering[User] = Ordering.by(_.name) (anonymous, resolved by type) or given userShow: Show[User] = ... (named, for explicit reference). A using clause requires one: def sort[T](xs: List[T])(using Ordering[T]): List[T] — the caller supplies it explicitly or (usually) the compiler finds it. Type classes are the composition: a trait defines the operations, given instances implement them per type, and functions constrain with using clauses; the compiler assembles instances for composite types from their parts. summon retrieves an instance explicitly (summon[Ordering[T]]) when you need the value rather than just its methods. Resolution — the compiler's search — looks in lexical scope, then the companion objects of the types involved (the given's type and its type arguments), a well-defined order that makes instance placement a design decision.
Middle row: the ergonomics. Context bounds abbreviate the common case: def max[T: Ordering](xs: List[T]) desugars to a using clause, keeping signatures clean. Extension methods add operations to existing types without wrappers or conversions: extension (u: User) def displayName: String = ... — and type-class extensions (extension [T](x: T) def show(using Show[T]): String) give the x.show syntax that makes type classes pleasant to use. Derivation generates instances mechanically: case class User(...) derives Show synthesizes the Show[User] from the structure (via the type class's derived given using Mirror — Scala 3's compile-time structural reflection), eliminating the boilerplate of hand-writing instances for every case class. given imports make contextual scope explicit: import scope.given brings given instances into scope deliberately (versus Scala 2's silent implicit imports), so 'which instances are active here' is answerable by reading imports.
Bottom rows: keeping it sane. Coherence and priority: the ideal is one canonical instance per type (placed in the companion object, always in scope, never ambiguous); when multiple candidates exist, specificity and priority rules (and explicit low-priority given traits) resolve them — but ambiguity is a design smell signaling you've defined competing instances. Migration from implicit is largely mechanical (implicit val → given, implicit parameter → using, implicit class → extension), and the result reads better and errs less. The ops strip: resolution debugging (the compiler's -Xprint:typer and improved 'no given instance found' errors that suggest what's missing), import discipline (given imports explicit and minimal), and API design (instances in companions, coherence maintained, extension methods for ergonomics).
End-to-end flow
Build a small serialization type class and watch the machinery compose. trait Encoder[T]: extension (t: T) def encode: Json defines the capability with an extension method for value.encode syntax. Given instances for primitives: given Encoder[String] = ..., given Encoder[Int] = .... A given for collections, parameterized: given [T](using Encoder[T]): Encoder[List[T]] = ... — 'if you can encode T, here's how to encode List[T]'. Now List(1, 2, 3).encode works: the compiler needs Encoder[List[Int]], finds the List given, which requires Encoder[Int], which it finds — the instance assembled by resolution from parts you defined independently. Add case class User(name: String, age: Int) derives Encoder and List(user1, user2).encode works too: derivation synthesized Encoder[User] from the case class structure (name: String — encodable; age: Int — encodable), the List given handles the collection, and no one wrote User-specific or List[User]-specific encoding code.
The design discipline shows in where instances live. The primitive and derived instances go in Encoder's companion object, so they're found by resolution without any import — coherent (one canonical Encoder[Int], never ambiguous) and discoverable (users never wonder which import provides it). When the team needs a different encoding for a specific context (say, dates as Unix timestamps in one API, ISO strings in another), they don't define two competing given Encoder[Date] instances (ambiguity, incoherence); they use a newtype or a explicitly-imported alternative given in the narrow scope that needs it — the coherence-preserving pattern the new syntax makes natural.
The migration and debugging vignettes complete it. Porting a Scala 2 module, the mechanical translation (implicit val → given, implicit param → using, implicit class → extension) clarifies intent immediately — a signature that was (implicit ec: ExecutionContext, enc: Encoder[T]) becomes (using ExecutionContext, Encoder[T]), unmistakably 'requires these', and an implicit conversion that had been silently kicking in is now a compile error demanding an explicit given Conversion — surfacing a latent type-safety hole the old code hid. When resolution fails ('no given instance of type Encoder[LocalDate]'), Scala 3's error names exactly what's missing and where it looked, and the fix is a one-line given in the companion — versus Scala 2's infamous 'could not find implicit value' that sent developers hunting. The team's standing rule crystallizes the discipline: instances in companions, coherence per type, extensions for syntax, given imports explicit — and contextual abstraction stays a superpower instead of becoming a mystery.