Well how 'bout locking/unlocking those tables to prevent this from happening ?

Dunno. Maybe that'd work. But if a module's users have to even consider adding such things, then it doesn't bode well for ...

... that it probably is a good module.

A pretty basic requirement of a "reliable job queue", is that once you take a job out of the queue, nobody else will be able to.

Even ignoring the complexity problems of the implementation, I think that using an RDBMS as the basis of a distributed queue is fraught with problems architecturally speaking. RDBMSs are designed to be servers in a client-server world; supreme masters of the data they control; responsible only for ensuring the total coherency of that data at all times.

Whilst the big boys -- Oracle, IBM, MS et al -- have add-ons for running their RDBMSs on clusters, they only achieve reliability by throwing multiply redundant high-availability hardware at the problem. Running one of the lesser-mortal free RDBMSs on commodity hardware is never going to achieve reliability.