I'm not sure if that's a bug but I always thought the fastRedstoneDust option shouldn't break any contraptions.

For example if you want to create a 0-tick like that (the bottom piston has to be sticky, place the redstone block at the end)

it is locational if it works or not with fastRedstoneDust enabled but it always works if fastRedstoneDust is disabled (it doesn't work if the pistons are south or east of the redstone dust but it works if they're north or west of the redstone dust).

There are more examples where fastRedstoneDust breaks some 0-ticks but they're more complicated to explain.

This piston door for example doesn't work if fastRedstoneDust is enabled but does work if it is disabled:
https://youtu.be/r23hmRQLNh4
https://youtu.be/TIe9APEOaXc

The rule description (also available in-game) mentions that not all behaviour is guaranteed to be exact, so I'd think this would be expected, but I don't know for certain.

It's an unfortunate result of the order in which neighbors of a wire are updated. The way these updates are carried out means that, once the wire going into the target block is powered, the bottom piston is updated before the top piston. The update order was chosen after testing several candidates, so I don't think this can easily be fixed without risking breaking other circuits.

The documentation in the code says the following about the update order:

This update order was selected after experimenting with a number of alternative schedules, based on its compatibility with existing redstone designs and behaviors that were considered to be intuitive by various testers. WARBEN in particular made some of the most challenging test cases, but the 3-tick clocks (made by RedCMD) were also challenging to fix, along with the rail-based instant dropper line built by ilmango. Numerous others made test cases as well, including NarcolepticFrog, nessie, and Pokechu22.