The main argument brought up in TrooperTony's post is that the new behaviour is in conflict with what FFF-389 and FFF-395 show. I believe that the setup in these FFFs has been misunderstood.

The setup that Wacker presented has separate station names for each individual item's loading station, and ...

A new bug report has been opened to ask about the reversal of this change: 122309 I would kindly ask all discussion to be directed over there, to have everything in one place.

Thanks again for the report. Starting with 2.0.21, the GUI won't allow entries below 1.

Thank you for the report, your autosave helped narrowing down what the issue was. A fix will be included in the 2.0.21 update.

For those interested, this crash had to do with "waypoint" stops, stops in the schedule without any conditions, causing the train to pass through the station without ...

Thanks for the report. A fix for this issue will arrive in version 2.0.21.

Thanks for the report. This issue will be addressed in the next version.

This is not a bug, this is a deliberate choice made specifically for conditions containing the "Each" signal.

It's possible to setup conditions like e.g. "Each > 10 AND Each < 100", where it's tricky to find highlighting rules that are both intuitive and easy to implement. Therefore conditions with ...

This is not a bug, this is intended behavior. Rails need to conform to the 2x2 grid, and blueprints get adjusted to follow these rules.
If you tried saving the blueprint after step 3, it would have given you an error.
If you want to keep the odd grid position, either pick an odd absolute position to ...

Thank you for the report. A fix for this issue will come with the next update.

Thank you for the report. The issue will be resolved in the next release.

Looking into it, this is a duplicate of 115988. In this case here, the schedule advanced, looped around to the top to the 'Supply' station, and then (erroneously) placed the interrupt station after that station. It only seems to go backwards because of how short the schedule is.

Thanks for the report. The issue has been addressed in the next update.

Thank you for the report. The issue has been fixed in the next version.

I can't replicate the issue using the steps you named. With just these two changes to the keybinds the furnace gets mined immediately.

Do you have more keybinds that differ from the default?

Thanks for the report. The issue will be resolved in the next release.

Thank you for bringing this pressing issue to attention. A fix will be included in the next release.

And you were right, the bug happened when the description was long enough to need line wrapping.

Thanks for the report. A fix will be included in the upcoming release.

Both your suggestions have been implemented, in order to have fuels and modules behave the same:

Excluded fuels get listed with a count of 0, as long as there are other, non-excluded fuels still present.
The same logic was ...

I investigated further, and found the culprit for creating the overcompression: Neither you nor your friend have rotated the belts hundreds of times, but a mod has. "EditorExtensions" rotates every built and upgraded belt clockwise one full circle in search for the mod's infinity-loaders and linked ...

Thanks for the report. A fix will be included in the next release.

Thank you for the report. While I could not figure out how that line of items got compressed like that, a fix for the overcompression not disappearing will be included in the next release.