language: allow pattern constraints to be "scoped"

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.13.0-0.dev.0.20250306134408-5d2da079a295

go version go1.24.0
      -buildmode exe
       -compiler gc
  DefaultGODEBUG gotestjsonbuildtext=1,multipathtcp=0,randseednop=0,rsa1024min=0,tlsmlkem=0,x509rsacrt=0,x509usepolicies=0
     CGO_ENABLED 1
          GOARCH arm64
            GOOS linux
         GOARM64 v8.0
             vcs git
    vcs.revision 5d2da079a295feae310b4f8e9aa0a030a056cda1
        vcs.time 2025-03-06T13:44:08Z
    vcs.modified false
cue.lang.version v0.13.0

What did you do?

In various situations, the need for "scoped" pattern constraints has reared its head. Most recently in #3674. But it has come up in my own configurations, and @rogpeppe has evidence of this need too.

Pattern constraints generally provide a nice aspect-oriented way of declaring constraints on values. However, there is currently no way of limiting the "scope" of such pattern constraints. Consider the following:

foo: [string]: source: "_foo"
foo: {
	a: i: 0
	b: i: 1
}

bar: {
	c: i: 2
	d: i: 3
}

bar: {
	[Key=_]: {
		j: 1
	}
}

baz: foo & bar

There is no way currently of "limiting" the pattern constraint declared on foo to that field, such that it doesn't then participate in the unification to form baz.

#3674 (comment) presents a means of working around this using comprehensions, but that doesn't feel particularly satisfactory.

Noting that this problem also exists in the Go API with cue.Values.

What did you expect to see?

Some means in the language for limiting the scope of pattern constraints. Maybe we would support this via some kind of builtin that "strips" pattern constraints, something akin to finalize() perhaps (see #943).

What did you see instead?

As above.