Yes, that's how it's supposed to work. However, the current ROS implementation of OSPF has a bug where if a router is injecting a prefix into OSPF based on a "floating static" route (this is true for default-originate routes and for any redistributed routes, whatever the source), the OSPF process will ignore this prefix if it learns it from some other OSPF source.
So to make it easier, let's make an example:
route to 192.0.2.0/24 is normally learned via OSPF (Distance=110)
floating static route to 192.0.2.0/24 is configured with distance > 110. (e.g. 254)
Normal condition: router uses the ospf-learned route.
OSPF withdraws the prefix
Floating static route becomes available
This router now injects 192.0.2.0/24 into OSPF based on the now-active floating static route
Original source of the 192.0.2.0/24 prefix is restored, and ospf sends this LSA to the "floating static backup" router.
The backup router installs the original route, but leaves it disabled, so the floating static route will never be withdrawn.
The reason is because normally, an OSPF router should never use a learned route to reach a prefix which the router is also itself injecting into OSPF, as this can lead to routing loops.
Mikrotik's solution to this rule is that it ignores the prefix entirely, when what it should do is stop injecting the route and start using the OSPF route. I reported this behavior to Mikrotik over a year ago, and was told that this behavior will be addressed in RouterOS 7. In the mean time, the only way to "normalize" your routing is to go into the backup router and manually disable the floating static route so OSPF will revert to the correct path, and then re-enable it so that it will work again the next time the primary route fails.
When given a spoon,
you should not cling to your fork.
The soup will get cold.