this is making sense and erring out now

wording nit:

The error message should print out the defaults, to improve failure locality (the cost of mapping a failure to a particular place in code). Ideally, it'd even emit line numbers, like native CUE errors do, but that's more than we need to worry about right now.

debug output needs removal

Same as other comment, print out the conflicting default values in the error message

This is a really interesting question! It should probably be a comment in the PR, or even its own issue, rather than hiding it in an actual committed file, i think.

My intuition is that, first and foremost, we have to follow the constraints imposed by TypeScript's own rules. From there, we should do the least magical thing possible. Given that, my initial thought is to allow this, as:

export enum AOrEnum: {
  Foo: 'foo',
  Bar: 'bar',
  Baz: 'baz'
}

export interface Foo {
  Bar: AOrEnum | "ohai"
}

export const defaultFoo: Foo = {
  Bar: "ohai"
}

At first, this seemed reasonable, because of what i felt i could infer about authorial intent:

1. There's an author of AOrEnum, who expressed the intent that the default value of their type be baz
2. There's an author of Foo, who is (clearly) directly aware of AOrEnum, as they wrote some text explicitly referencing it.
3. Foo's author, being ostensibly aware of AOrEnum, is choosing to supersede the default of baz with ohai.

However, going through this exercise led me to realize that this case is narrow and circumstantial, not based on generalizable principles of the sort people can reason about. That's because we're bumping into fundamental differences in the models on which CUE and TS are based:

1. Defaults are a native concept in CUE that authors must deal with; no such concept exists in TS
2. The primitive kinds in the languages are simply different (disjunction semantics in CUE; existence of enums in TS)
3. While both TS and CUE are mostly structurally typed, which generally it possible to flow types through the system more freely than if names must strictly align, we're (necessarily) making that harder by trying to snapshot bits of the system to translate from CUE to TS, without ever being able to guarantee that we have the whole type graph to examine for completeness or correctness

i don't know what our good answers are here, yet, but the above sort of reasoning makes me reasonably sure there simply aren't any, and we shouldn't waste time or effort searching for them. Instead, we should be very conservative in what we support, erroring aggressively when the slightest bit of ambiguity arises about how to e.g. handle a default or flow an enum into an interface, and then consider opening up further when use cases present themselves.

That's still not a clear, categorical rule we can apply easily, but...well, it's a general basis for saying no and constraining scope, which is usually a safe place to be.

All that said, it's worth noting that CUE seems to follow the same logic about user intent/awareness that i originally ran with - see this playground, and note that C has a single default, but D does not. Which is...actually really interesting, and potentially useful.