This resolution will make a ton of business apps based on desktop database software that much closer to working.
I'm not so sure. I expect most database software depends on the mandatory nature of LockFile(), i.e. that a ReadFile() or WriteFile() from another process on a locked region fails with ERROR_LOCK_VIOLATION. Typically, one process will LockFile() an area, then update on-disk structures in such a way that another process reading during the update would get confused were it not for ReadFile() refusing to read the locked bytes. Note that the reading process does not LockFile() to read, it just tries ReadFile() and handles its failure (typically by waiting and trying again later).
For database software that uses read/write locks via LockFileEx(), the standard Unix advisory lock semantics are just fine, and those patches are indeed the ticket. However, advisory locking is generally more difficult to manage, and LockFileEx() is not supported on Windows 95/98/Me, so I doubt many apps use it.
From what I can tell, mandatory locking on Linux involves tricks like using a
special mount option, and setting the SGID bit of the file to be locked before the locking process starts; I'm not sure which other Unixen even support it.