Is one shared drive for Steam games across Windows and Linux workable, or does it just keep breaking?

The honest answer is closer to the second one than people want to hear, and the reason is worth understanding because it explains every symptom you listed.

A game on the two operating systems is often not the same set of files. For a title with a native build, Steam downloads a different depot per platform. Point both at one library folder and each side sees files it does not recognise as its own, decides the install is damaged, and repairs it — by redownloading. That is your "verifies and redownloads" case, and it will do it every single time you switch. It is not a bug, it is two clients with different ideas about what should be there.

For a Windows-only title run through the compatibility layer, the game files genuinely are the same, and this part can work. But the runtime state is not shared: the compatibility layer keeps a per-game prefix containing a synthetic Windows filesystem, the registry, saves for games that write to the user profile, and installed redistributables. That lives outside the library folder and is Linux-only. So even in the good case you are sharing the payload and not the installation.

And then the filesystem itself. If the shared drive is NTFS:

• Case sensitivity. NTFS preserves case but does not distinguish it; Linux filesystems do. Games and the compatibility layer occasionally rely on this and fail in ways that produce exactly your "installs, will not start, no useful error".
• Permissions and ownership. The Linux driver fabricates these, so anything expecting to set a file mode gets a polite lie. Mostly harmless, occasionally not.
• Symbolic links. Several games and the compatibility layer create them. Support on NTFS from Linux is partial.
• The mount must be clean. If Windows was hibernated rather than shut down — which Fast Startup does by default — the NTFS volume is left dirty and Linux will either refuse it or mount it read-only. Steam then behaves very strangely indeed.

What I ended up with after trying all of it:

• A separate library per OS for anything with a native build. No cleverness, no shared folder. Disk is cheaper than the evenings.
• One shared drive for large Windows-only titles, used from Linux only, with Windows treating it as ordinary storage rather than a Steam library. You get the space saving where it matters most, and the case that actually works.
• Fast Startup off, permanently, no exceptions. This is non-negotiable if a Linux system ever touches an NTFS volume Windows also uses.

If you want one thing to change first: turn off Fast Startup and stop trying to make the same library folder serve both clients. Keep the drive shared, keep the libraries separate.

If you are willing to give up seamless access from the Windows side, the cleaner arrangement is a Linux-native filesystem on the shared drive and a driver on Windows for the occasional read.

You get real permissions, real case sensitivity, real symlinks, and the Linux side stops fighting the filesystem. The trade is that Windows access becomes second-class, and third-party drivers for Linux filesystems on Windows vary in quality — treat that direction as read-mostly and do not run a game from it.

Worth it if the majority of your gaming has moved to the Linux side. Not worth it if it is genuinely fifty-fifty.

The Fast Startup point deserves more emphasis than it usually gets, because the failure is not always loud.

A dirty NTFS volume sometimes mounts read-only rather than refusing. Steam then cannot write, and what you see is games failing to update, saves not persisting, and a library that seems to randomly revert. Nothing says "the disk is read-only" anywhere you would look.

Check how the volume is actually mounted before you debug anything else. If it says read-only, everything downstream is a symptom.

And properly off means the power option, not just avoiding hibernate. "Shut down" with the feature enabled is a hibernate.