Sure, but the problems being addressed by this proposal are here today and we have every reason to expect they'll continue to grow. In contrast, nobody's even floated an idea for a way to get computation that—like all ordinary computation in Swift, the system is allowed to perform at run-time—back into the type system, and as I've mentioned, forcing any such computation to happen at compile-time clashes mightily with Swift's fundamentals. We need to make progress based on what's viable (and implementable!) today, not some abstract idea of what might be possible someday if someone figures out how to do it.
Protocol conformance is a relatively well-factored part of the system: whether a type conforms to a protocol, and what that tells the rest of the type system about what you can do with the type, is orthogonal to how the members of the conformance get computed. If we were to introduce a Turing-complete decision process for picking witnesses, or for generating them via compile-time evaluation, that wouldn't affect the decidability of the rest of the type system, which only needs to know that the conformance exists.
I agree with that—it's one reason I'm not afraid of type-level metaprogramming—but don't understand why you're saying it.
That's not a problem if the conformance doesn't cross a resilience boundary, which is what the scoped conformances proposal is about.
That sounds interesting, but I don't really understand how it would play out. Can you give an example?