@milseman, you were working on this, right?

Yes

Aha, popFirst and friends should only be on Collections who are their own Subsequence types. String and associated views should not be their own Subsequence types. Earlier betas had a bug where they were, and even b5 still has a bug where String.CharacterView when explicitly called out is still its own slice type. This bug causes potential "leaks" that Substring was designed to fix, not to mention they pollute the model. There also likely needs to be more compatibility affordances provided by the standard library to improve diagnostics here and ease a migration path (e.g. deprecated rather than unavailable).

As far as this error specifically, that's a very unfortunate error message. I'll see what I can do to hunt it down.

TL;DR: It is by design that Substring and its views have popFirst defined, while String does not. Substring's popFirst does not mutate the underlying String, it just advances the Substring's startIndex. The current implementation, however, has bugs that hurts the user experience.

I'll add popFirst as being unavailable on String and its views for a better diagnostic message. Bikeshedding time, what's a good diagnostic here? Strawman:

error: 'popFirst()' is unavailable:
String.UnicodeScalarView is no longer its own SubSequence type; please use 'first', 'dropFirst()', or 'Substring.UnicodeScalarView.popFirst()'.

edit: JIRA formatting

@swift-ci create

Fix is part of #11373 which is pretty closely related and fixes the dangling String.CharacterView issue.

edit: Specifically, this hash: a5933d2

4.0 PR: #11806