I'm kind of new to game dev and I'm a little confused about the terminology you're using. You called Bevy a framework to differentiate it from an engine, but on the Bevy website they call themselves an engine. What would you say is differentiation between a framework and an engine?
While I've never seen it defined this way, I think the distinction comes down to this:
An engine deals with assets in depth, and exposes runtime abstractions to them.
A framework does what is necessary to expose I/O and load the assets, but aims to be minimally opinionated about how they integrate into the application.
For example, in an engine you might have abstractions for applying collision, physics, and rendering techniques onto an image asset, so that you can achieve a useful result just by configuring the data correctly. A framework would give you a way to load the image and display it, but leave it to you to add more detailed behaviors by writing new code.
In effect, engines are never totally done until you have a feature-complete application. Often it works out that you need a scripting layer to define a certain kind of asset(e.g. dialogue tree logic), and then what you have is an engine extension; if the asset is defined independently of the scripting system, it can be made portable to another engine.
I think the key difference in most people's eyes is: am I interacting with this mostly through code (framework), or is there a substantial amount of graphical tooling that aids me (engine)?
I'd say Bevy today is more akin to a framework, but they intend to add tooling etc. to become closer to an engine later on from what I understand.
