事实并非如此，我们在内部和外部都反复看到过这种情况，并且在整个代码库中也是如此。
我还没处理到分类（categories）部分，这里没有任何变化。
人们压倒性地使用 TL0 来表示“所有已登录用户”，因为我们没有更好的方式来表示这一点。logged_in_users 组至少在其含义上是完全清晰的，而且你完全可以继续使用 TL0/TL1 等。唯一被移除的组是 everyone。
是的，我确实只是为了“为了改变而改变”才做这些 
请暂时考虑一下你的措辞，我们这里并没有习惯毫无理由地做完全不必要的事情。这项工作已经持续数月，并且不会改变方向。
好吧，也许是我误解了这个改动？
如果提案是引入以下自动用户组：
这看起来没问题，而且含义也很明确。
（实际上我挺喜欢这个方案的！）
然而，如果提案是最终移除：
这在我看来就不合理了，因为“所有人”是代表访问权限阈值的一组自动用户组的一部分，该组还包括：
等等。
它们全部代表访问权限的阈值，包括“所有人”。
“所有人”组也被称为“trust_level_none”（无信任级别）。
这是一种简洁地表达“公开访问”的方式。
我理解你目前并没有提议在分类权限中移除它（），但就我个人而言，我希望看到对保留此自动用户组的承诺，因为至少对我来说，这是有道理的。
那么，为什么不允许它在其他地方像其他任何自动信任级别组一样被使用呢？
否则，每当你需要表达具有“公开访问”权限时，你就需要添加两个组，这似乎是一种毫无意义的复杂性？
为什么要费心去添加逻辑来“屏蔽”“所有人”呢？
也许另一种替代方案是，如果存在更好的名称，可以重新考虑“所有人”这个名字，但保留其含义、功能以及在平台上的可用性，这样大家（咳咳）就都满意了？
我认为这里的区别在于：是保留一个方便选择“公开访问”的方式，还是保留现有的 everyone 组。我同意，每次想要公开访问时都需要选择两个组确实更麻烦，我们可以通过界面（UI）来改进这一点。
例如，我们可以在组选择器中添加一个“公开”快捷方式，一次性同时选中 anonymous_users 和 logged_in_users。这样你会看到两个组都被选中，并且可以移除其中任意一个。这既提供了你所描述的便利性，又保持了底层权限的明确性。我们只会在允许这两个组的地方提供该快捷方式。
保留现有 everyone 组的问题在于，它并不始终意味着“公开访问”。在类别可见性方面，它确实如此，但在大多数基于组的站点设置中，它实际上意味着“所有已登录用户”。此外，正如上面的讨论所示，不同的主题和插件对其解释也各不相同。
因此，我们不能简单地保留它并声称它在所有地方都包含匿名用户，因为这可能会授予之前不存在的访问权限。保留其现有行为会维持这种不一致性，而重命名它也无法解决这一问题。
定义一个一致通用的组是可行的，但这仍然需要我们目前正在进行的迁移和审计工作。此外，在不支持匿名访问的地方，它也必须被禁止，否则我们又会回到“everyone”在那些地方仅意味着“仅已登录用户”的局面。我不得不在许多设置中将 anonymous_users 添加为 disallowed_groups 的值，而在之前 everyone 在这些设置中是允许的。例如：
我倾向于在 UI 中提供这种便利性，底层使用两个明确的组，这样管理员和开发者在所有地方都能保持一致性。
每个人都非常明确——在我看来这似乎是不必要的繁琐——但我确实欣赏保留的便捷性。
在我看来，问题在于此，而不是原始的“everyone”（所有人）类别概念。
“everyone”群组及其在基础类别系统中的应用已经存在了……2013年？
如果设置系统发生了偏离并破坏了这一约定，那难道不是设置系统工作方面的问题吗？
在我看来，在似乎直接朝着实施方向前进之前，最好能有一个 RFC（请求意见稿），让社区有机会为此贡献想法。
如果我遗漏了什么，请见谅……
是的，我同意站点设置中的不一致性是问题的一部分。但解决这个问题并不意味着必须继续将现有的 everyone 组用于站点设置。
我认为 2013 年的论点除了说明 everyone 在分类权限中存在了多久之外，并没有告诉我们太多。自 2013 年以来，Discourse 发生了很多变化；例如，许多站点设置过去是基于信任等级的，现在则是基于组的。没有人会质疑在这种语境下这样做是合理的，而且分类权限在此次工作中并未改变（至少目前是这样）。它的存在时间并不能证明它在 Discourse 的其他部分具有一致的含义，或者我们应该无限期地保留它。
即使我们同意所有偏离原始含义的情况都是错误，我们仍然必须处理这些设置在现有站点上的实际行为。我们不能仅仅因为包含匿名用户能更好地匹配原始分类行为，就安全地更改它们的解释。正如我上面所解释的，保留一个含义一致的通用组仍然需要审计和迁移这些用法。这是一种替代设计，但它并没有避免这项工作中困难的部分。
关于 RFC 的观点，在进行此类更改之前有一个社区 RFC 会显得缓慢且难以承受，尽管欢迎反馈，这正是即将推出的变更系统（change system）的目的所在。这个主题已经根据 Moin 的例子带来了多项改进，我也承认并修复了我最初遗漏的主题/组件案例。
我很乐意继续处理与变更相关的具体问题，但我仍打算推进这两个显式组。在 UI 中让公开访问的选择变得方便似乎是解决额外点击问题的合理方式，但我不认为现在必须立即实现它。
总之，我仍在 The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions 中跟踪了大量与此相关的工作，因此这需要一段时间，任何与分类系统相关的更改也是如此，分类系统暂时仍保留 everyone。分类很可能会迁移到我们称为 ACL 的系统，Kanban 已经在使用该系统：
