I am _very_ happy with using ECS for the core of the engine. But this is a _very_ nuanced topic. We do not meaningfully "use ECS everywhere", which is a common characterization ("square peg round hole"). I have long been an advocate of "not ECS-ing everything" (even though we do ECS a lot of things in Bevy). I'm often providing backpressure to "lets ECS this thing" in Bevy.

First some clarity: ECS isn't just one thing. It is a broad category. For example, Bevy ECS has a variety of ways to store data (tables, sparse sets, custom storage in "resources"). We try to use "the best tool for the job" based on the problem we are trying to solve. For some engine features we represent data as Components / Entities (stored in either a table or a sparse set). For other engine features we use hash maps, dense vectors, generational arenas, atomic reference counted pointers, etc. We store these types as "ECS Resources". Bevy ECS is as much about providing easy access to non-ECS things as it is about providing access to components stored in a particular storage backend. Imo the "resource model" is way better than just defining global variables like many other engines do.

_Every major engine_ has some kind of "data layer" that makes describing data and composing behaviors easy, principled, and consistent within the engine. This data layer will tie into things like visual editors, scenes, save files, debuggers, etc. For Bevy, we call this data layer Bevy ECS. Again: it is multifaceted and flexible.

I'm familiar with the recent discussions on Twitter (ex: Seb brought it up in the context of renderer dataflow and other prominent people chimed in). We've actually independently (as in over the past 6 months or so) decided that using ECS table/sparse set storage _for renderer dataflow specifically_ is suboptimal for us. The "archetypal ECS" approach to tracking the components an entity has and building unified storage for fast iteration is not worth the overhead of constructing the storage. The way renderer data is constructed and accessed does not align well with that. The 2D side of Bevy Render already doesn't use Entities/Components to draw sprites (and instead opts to store this data in dense Vecs). We've been discussing the best way to adapt the other parts of the renderer to transition to a similar model.

We will continue learn + adapt. We use ECS storage (as in Entities with Components stored in a particular storage backend) in places where we think it is the best fit and not in places where it is not. I believe the result in Bevy (user experience, performance, API) is excellent (and others seem to agree).