Interesting, thanks! I'd always thought (as I mentioned above) that it was not recommended to put a library on a network location, and also not to point two copies of MC at the same library. The former because of performance issues, and the latter because of file locking/update issues. But perhaps this is sorted now. As MrC says, perhaps MC knows that one copy has already got it open and therefore only opens it in read-only mode. This is probably what you have discovered - that updating the library using the second computer doesn't work because the first one already has it open.
If you link to a library with a code then you are linking to a particular MC instance, therefore even if the common library resides on a NAS, you are linking to the copy of MC that is using the NAS, so in this case you will still need that computer switched on.
But in theory, if this does work, then it solves the problem of using library server to have to sync changes between computers. It would then be possible to rip, tag etc from any computer to the same library, with the caveat that there can only be one updating computer at any one time, so I guess you'd have to shut down one copy if you planned to update using another computer. But that's ideal really, as many people want to be able to maintain the database using an "office/study" PC but still access the same library from a HTPC in the living room, which is not possible using library server. This is what has stumped me so far.
It's still not true client/server though, it's as though all copies of MC have their own local library. They're not using server technology at all, they're simply using Windows file sharing.