The issue in question seemed to arise when connecting a network (powered by furnace engines, run through an RSC stepping up) to a processing setup a short distance away (potentially a chunk issue, though all chunks were force-loaded).
When attempting to use the Controller to step down the RPM of the system, the Controller broke as if it were the block running at an incompatible speed. Following this, the rest of the system, while now no longer attached to any power generation, continued to run at the RSC's increased speed and system's stress capacity. (Notably, turning off the furnaces at this point still affected the SU capacity, as if they were still connected.) Note that attempting to re-attach the Speed Controller would also result in it being broken again.

The issue was eventually traced back to a connected point in the system, a small assembly of various machines, belts, and chain drives with no generating components, which applied said system power to any other attached network objects. (Note, at this point, after a re-launch, the apparent stress capacity of the "ghost" system had doubled, from 65536su to 131072su.)

Possible points I can imagine to consider may be

• Desync between generators and consumers caused by chunk boundaries
• Systems no longer recognizing Rotational Speed Controllers as the part enforcing the speed of a network, causing it to break without updating the rest of the system (This seems most plausible, though I'm not entirely sure the behavior in-code.)
• Some potential arrangement of chain drives, gearboxes, and machines, which for some reason causes the system to exhibit this "decoupled" power.

The issue apparently does seem to go away if you break and re-place enough components near every consumer (for example, replacing attached chain drives), so if this occurs in a world, it can be resolved with some re-placing.

I can provide a world save which currently exhibits the issue, however I have not yet attempted to replicate it. Note that the world is attached via a google drive link, due to its size, even when compressed.
In addition, I have a small number of recordings taken during the diagnostic process, though given file size constraints, I'll begin with simply including the world file for manual testing if that's enough.

Google Drive World Download

EDIT: Additional information; Installed pack is Direwolf20's 1.16 Pack, with Forge 35.1.11 and Create 0.3b.

I think I have a similar problem right now where my setup got overstressed and even if I take away everything from the furnace engine it still keeps saying it's overstressed. Tried remove it and put down again on another location and it worked but if I put it back at original location it still says overstressed. https://imgur.com/a/eGR66c2

I also had chunkloading and things on different chunks. On All the mods 6 1.8.5 (Create 0.3.2d/Forge 36.2.6)

This issue has been marked as stale because it has been inactive for 3 weeks. It will be closed if it remains inactive for another 3 weeks.

This issue has been closed since it has been inactive for 3 weeks since it was marked as stale.

That does seem consistent with my world file in that case; The assembly in particular is an indirectly-connected set of chain drives and the blocks which carried the "ghost" force seemed to mainly be around where multiple chain drives and gearboxes intersected across multiple directions. Definitely not a certainty, but that does seem like a consistency that could be related.

Both times I've had this issue the majority of the final spinning blocks were chain drives so I think it's likely it is somehow related to them.

EDIT: Create 0.3e and forge 36.0.1 for me