cue: unification of open struct with a let expression fails

[errordeveloper]

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

v0.5.0-rc.1

Does this issue reproduce with the latest stable release?

No.

What did you do?

exec go mod tidy
exec go run main.go
-- go.mod --
module m

go 1.19

require cuelang.org/go v0.5.0-rc.1
-- main.go --
package main

import (
	"fmt"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/cuecontext"
	"cuelang.org/go/cue/errors"
)

func main() {
	ctx := cuecontext.New()

	schema := ctx.CompileString(
		`package types
		 #T: {
			...
	    	 }`,
	).LookupPath(cue.ParsePath("#T"))

	data := ctx.CompileString(
		`package foo
	    	 let foobar = {}
	    	 _fb: foobar
	        `)

	fmt.Println(errors.Details(schema.Unify(data).Validate(), nil))
}

What did you expect to see?

No errors.

What did you see instead?

#T: field not allowed: foobar

[mvdan]

A slightly shorter reproducer, which shows the success on v0.4.3 and failure on v0.5.0-rc.1:

exec go get cuelang.org/go@v0.4.3
exec go mod tidy
exec go run main.go
! stdout .

exec go get cuelang.org/go@v0.5.0-rc.1
exec go mod tidy
exec go run main.go
! stdout .

-- main.go --
package main

import (
	"fmt"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/cuecontext"
	"cuelang.org/go/cue/errors"
)

func main() {
	ctx := cuecontext.New()
	schema := ctx.CompileString(`
		#T: {}
	`).LookupPath(cue.MakePath(cue.Def("#T")))
	data := ctx.CompileString(`
		let foobar = {}
		_use: foobar
	`)
	fmt.Println(errors.Details(schema.Unify(data).Err(), nil))
}
-- go.mod --
module test

go 1.19

$ testscript -v -e GOMODCACHE=$(go env GOMODCACHE) repro-go.txtar 
> exec go get cuelang.org/go@v0.4.3
> exec go mod tidy
> exec go run main.go
[stdout]

> ! stdout .
> exec go get cuelang.org/go@v0.5.0-rc.1
> exec go mod tidy
> exec go run main.go
[stdout]
#T: field not allowed: foobar

> ! stdout .
FAIL: /tmp/testscript2657663051/repro-go.txtar/script.txtar:9: unexpected match for `.` found in stdout: #
error running repro-go.txtar in /tmp/testscript2657663051/repro-go.txtar

[mvdan]

Unsurprisingly, this bisected to 36bd656, which is the CL I had already mentioned in the original discussion on Slack.