I think the distinction here is between keeping a convenient way to select “public access”, and keeping the existing everyone group. I agree that having to select two groups every time you want public access is more cumbersome, and we can improve that with UI.
For example, we could add a “Public” shortcut to the group picker which selects both anonymous_users and logged_in_users in one action. You would then see both groups selected, and could remove either one. That gives you the convenience you’re describing, while keeping the underlying permissions explicit. We would only offer that shortcut where both groups are allowed.
The problem with keeping the existing everyone group is that it hasn’t consistently meant “public access”. For category visibility it does, but for most group-based site settings it has effectively meant “all logged in users”. There are also themes and plugins interpreting it differently, as the discussion above has shown.
So we can’t just keep it and say it includes anonymous users everywhere without potentially granting access that wasn’t there before. Keeping its existing behaviour would preserve the inconsistency, and renaming it wouldn’t resolve that either.
A consistently defined universal group would be possible, but it would still require the migration and auditing we’re doing now. It would also need to be disallowed anywhere anonymous access isn’t supported, otherwise we’re back to “everyone” meaning “only logged in users” in those places. There are a ton of settings I’ve had to add anonymous_users as a disallowed_groups value where it wasn’t before, and before everyone was allowed on those settings. For example:
I’d prefer to provide that convenience in the UI, using the two explicit groups underneath, then we have consistency everywhere for admins and developers.