Призываю переименовать Layers в Feature-Sliced Design методологии

Ох уж этот фронтенд. И я даже не про то, что такая организация - привет из времён PHP4, уже тогда под эгидой MVC так организовывали проекты. Тут страницы, тут шаред, тут модули, в модулях какие-то свои фичи, изолированно, глобальные фичи, локальные и глобальные компоненты и бог знает что ещё.

Это не FSD, это называется - проект организован из принципа необходимости, простоты и очевидности. Страницы - в страницах, все что нужно странице - в папке самой странице, что то используется в нескольких страницах? Да в тот же шаред.

Я это к чему - все эти очередные самые лучшие подходы (которые как правило - позабытое старое) не нужно воспринимать буквально. Оно в принципе не может всем подходить, это пример, как можно сделать. Если в вашем проекте не нужна какая-то часть, или ее нужно несколько изменить - да ради бога, это специфика вашего проекта или пожелание вашей команды, для большего удобства.

Никогда не понимал вот этой мании, понимать все буквально, делать как написано, ни шагу влево, все по методичке.

Вам так удобно? Вашей команде так хорошо? Новичкам въехать проще? Да ради бога.

Понятия - это те термины, которые вспыхивают в головах топ-менеджеров (пофантазируйте), когда они объясняют или рекламируют ваш продукт. 

Web3, NFT, Blockchain, AI, GPT, VR, AR, PWA, WPF, Gamification, CI/CD, Cloud, Serverless, SaaS...

Так вроде организация должна быть по бизнес логике, а не квадратное с квадратным, а круглое с круглым.
Такое применимо для небольших проектов, а когда организация проекта происходит по типу/назначению класса, контроллеры в контроллеры, енамы в енамы, сервисы в сервисы, а потом все референсят всех.

Ну штош, соболезную, сеньеров у вас нет :)

Скорее немного раздражает, так как по алфавиту было бы удобнее.

Недавно вышел FSD 2.1, который гласит о том, что если в проекте код из entity нигде не нужен, то его можно (скорее "следует" лучше подходит) переместить в features, если из features больше нигде не нужен - в widgets, ну и если и не в widgets, то в pages. Также в FSD 2.1 есть предложения о декомпозиции не только по бизнес-смыслу, но и по инфраструктуре.

Если рассматривать "pages-first" подход, то Вы можете разрабатывать фичи приложения не с точки зрения того, как лучше разделить это на слои, слайсы и сегменты, а как проще собрать целую страницу или модуль, и выносить уже общий код.

Что касается переименования слоёв и желания распространения это на методологию - всегда можно предложить это к обсуждению, например на том же гитхабе.