It won't (shouldn't) destroy the job. It will either continue to run, or the OS will pre-empt if the waiting job has a higher priority
(and then later continue to run the job that was pre-empted).
Rate monotonic isn't perfect. Scheduling algorithms have their strengths and weaknesses.
In fact, without a lot of apriori knowledge concerned with the tasks that are to be run, you can't even
pick the ideal algorithm.
By the way, even when people say a particular algorithm is implemented, the implementation
may have variations to the textbook definition, to make it easier to implement for example, or for
other reasons. So, you can have 'flavors' of particular algorithms. For example, some algorithms (I'm not
talking about rate monotonic) may not immediately pre-empt, but will rather allow a lower pri task
to run for a bit longer, even though a high pri task is now ready to run - sometimes the slightly extra time
allowed for a process can help in situations where the lower pri may never get a chance to complete
otherwise, and in fact may be causing the high pri one trouble, if the lower pri one is using a resource.
In that case, sometimes it is better to let the low pri task finish using the resource.
The best that the OS-developer can do is provide sufficient features in the OS, and to provide enough information to
the developer so that they can make best use of the algorithm(s) that are implemented.