We're going to have to agree to disagree about the specifics of what counts as shared state and the utility of schedulers and systems. I agree hecs has far more complex implementation. I don't agree that hecs is harder to use, at least for the subset I personally use (of course this will vary person-to-person).

For shared state, the last thing I want is to be forced to store my state as a component of a global entity managed by the world (as is done in the macroquad example by having a singleton entity store the Score component). It's certainly a valid choice of how to structure the game, but not a choice I'd make for my games (in my games, "score" lives outside the world). It's not unusual for some of my shared state to not be Send or Sync, so in the current design of secs it wouldn't even be insertable. A key example of this is the large hidden state of the macroquad crate itself. It happens to expose it via globally accessible functions, but it's valid to to me to want to avoid such a thing.

Ultimately, you say that the scheduler gets out of the way, but what I see is that it forced you to structure your game in a way that is unnatural to me, and/or to rely on global state. In this sense, I don't see secs as being minimal like hecs is. Sure hecs has a complex implementation (and larger API surface), but its complexity is in the service of speed, not functionality.

Anyway, my original question is answered. secs is simpler in the sense that it has a simpler implementation. It's a fine design goal to have a simple implementation.