The amended design is certainly more in line with the core team's requested exploration, and I think it is the right step. Some initial questions/comments:
I'm glad the issue with diacritics has been thoroughly discussed. It's nice that being 8 hours late to the party means I don't have to write more on that.
I have to say that I agree with @SDGGiesbrecht: I don't see the point of case-insensitive comparisons. Moreover, the security and ergonomic considerations you name argue against rather than for case folding, which could create rather than remove the very security problem you're trying to avoid:
Consider that each scope and package name will be subject to the policies of the registries that they are hosted on, and recall that there are locale-dependent case changes (cf. Turkish dotted i). If SwiftPM additionally applies its own locale-independent case folding, then a user could specify a {scope} and package name exactly correctly, and SwiftPM could apply case changes that are different from those of the registry's, thereby requesting a malicious squatter's code from the registry instead.
How so? Swift has never (to my knowledge) enforced any sort of maximum on package name length, nor of any variable or type. The length of any name is going to be bounded by registries to some maximum anyway, and more saliently, it will be bounded by what users will be willing to type into their package manifests.
Put another way, the question would be: Why is it important to you that every scope and every package name, regardless of where they are hosted, be subject to the same length limitation? Is there some attack vector made possible by exceedingly long package names?
Finally, Swift does not offer an NFKC normalization API; would we need to do so for this proposal to be fully implemented?