Ok. So you want the green collision events to capture collisions 'inside' this new proposed action of yours. That's the piece of the puzzle I was missing. I'm with Linky: I definitely see the appeal now, but it sounds too big a change to expect any time soon. As far as performance goes, though, I believe that you could actually get significantly better performance using forEach loops.
In your example where an object moves by 10px, in the majority of cases no collisions will actually be present. But with your proposed action, you're forcing Fusion to check collisions 10 times each tick anyway. It would be considerably cheaper to first check a larger primary collision detector that checks all 10 pixels at once. Then you only bother checking the 10x individual collisions in the (rare) cases where the primary detector hits something. If you know that your enemy will always move 10px then you just make your primary detector 10px wide. If your objects move by a variable amount, then you would scale the detector dynamically as needed before each test. The cost of calculating and scaling the detector, and the the cost of occasionally having to perform 11 collision checks instead of 10, would be far outweighed by the benefit of having to usually perform only 1 collision check instead of 10.
My enemy system uses a lot of these sorts of techniques, where I'm always trying to minimise the amount of collision checks and calculations the code needs to do. As a result, I can comfortably have almost 200 enemies in a level at 120fps, with them all running, chasing, jumping gaps, aiming, shooting, navigating slopes, AI, all done with smooth bicubic easing movements. I can get more than 300 enemies at 60fps, on my strong but aging PC. And this isn't just in a naked test, but inside my game, where I've already got loads of stuff eating up performance: 3000 objects, player movement, shaders, particle effects, 1080p, etc.
My enemy system contains 1000+ events (including 700+ 'on forEach loop' events), and 100+(!) different collision detector objects that all test for different things. To be clear, if I place all 300 enemies in front of the camera at once then the performance will plummet, partly because of the GPU load, and partly because many parts of my code only run for on-screen enemies (ie. visual stuff like animation switching, particle effects, Z-order). But in any real-world scenario that my game would actually use (eg. ~100 enemies on the level with ~10 on-screen at any one time), the performance hit of my forEach-based enemy system is virtually non-existent. Yes, it's a very complicated system (it took me a year to make), and I wouldn't recommend it for a beginner, but one of its benefits is its efficient performance. And I believe that its good performance is because I use forEach loops.
For example, here's a single enemy navigating some platforms. It needs to do a lot of things: look for holes or obstacles, decide whether to jump (and if so, test the distance and altitude of the landing spot, as well as for potential hazards, then calculate the arc of the jump), deal with sloped surfaces, aim, test line of sight to the player. Plus the engine has to constantly assess whether to display it behind platforms (eg. when on a ceiling) or over the top of them (eg. when on the ground)*. There are different detectors for each of these situations. But if you observe at how these detectors move in the GIF below, you'll notice that very few of them are tested each frame. Many are tested only once or twice per second, while others only get tested a few times in the entire GIF, as needed. The engine will even dynamically change the rate at which some of these detections are tested: if an enemy speeds up, it will start checking for certain collisions more often; if it slows down, then less often. All of this modularity is only possible because of forEach loops (or at least I think it would be a lot harder without them):
https://s5.gifyu.com/images/0EQguszuAy_2.gif
* You can see this glitch out towards the end of the ceiling-ride sequence, actually - I need to fix something there :/
