To your final point, I was wondering the same thing as well.
I've now tested five separate OpenELEC boxes running XBMC on two different ServerWMC servers and they all do the same thing. I've made countless configuration changes as well.
The only conclusions that I could come up with are that (1) I'm crazy, (2) most of your users are using Windows XBMC boxes (which probably don't have the issue), (3) most of your users are using Gotham (which may not have the issue), or (4) most of your users are turning their boxes off when they've not using them (and thus they rarely see "new recordings").
A library update isn't the only thing that fixes the problem. If I watch an older show first, or pull a directory listing, that seems to resolve the problem as well. As a result, the problem appears to be intermittent. Some users may have even experienced the problem, but because it went away when the restarted or tried another file, thought nothing of it.
Honestly, I don't know. But, I've spent about 20 hours on this so far, and this is the very best that I can come up with!!
If I understand what you've said, you don't supply any path at all for active recordings, and so it appears that the "PVR" link I see in the XBMC logs and in the ServerWMC logs are generated internally by XBMC when you leave the field blank. That also suggests that XBMC devs did intend you to provide an SMB link (in a completed path) and that kills my theory about the "bug" in ServerWMC. Obviously, if they gave you a field to include a SMB link, they intended that you might use a SMB Link, right?
Honestly, I have zero idea what the cause of this issue is. Sometimes, new recordings won't play.
I believe that I can induce the same issue by changing a file name on the Recorded TV Folder and waiting for the client to pull the new list. Every single time that I do that, the file won't play on any of my five machines, and the XBMC log shows the very same errors. The log will show that XBMC tried to play the correct SMB url, but it failed. The file will start playing again if I update the library, play another file, or reboot my system...
On your question about Windows clients, I haven't had a chance to fully test a Windows client. However, I did find that if I change a filename on a Watched Folder that is hosted by a Linux-based NAS (a ReadyNAS), the Windows client running XBMC Frodo had the same experience, i.e. once it pulled the new file list, it could not play the file until I did a library update...