With this kind of scheme, there is no guarantee that the MDF won't be corrupted when server A fails. Or the NAS fails.
The scheme ignores the LDF file. It is common for people to think that the LDF is not important, but this is not the case. The LDF functions as a write-ahead log and changes are "replayed" when an instance restarts (or the other instance starts, as in a cluster). You need the LDF or you will lose data.
Another thing to consider is that SMB-based NAS devices often have horrifically bad performance. If the device supports iSCSI, the situation probably isn't as bad. If you use SMB, using a mapped drive is a hassle. You will have to tweak SQL Server to store files on a network share.
If you want to avoid clustering, just do what everyone else does and look into database mirroring (which was introduced in SQL Server 2005) or log shipping (which can work with pretty much any SQL Server version, though official support did not debut until SQL Server 2000).
Following the crowd is usually the safest thing to do, though it might not be the most interesting thing to do. When you are dealing with a client's data, you want "safe", not "interesting".
Regardless of which tactic you use, there are other details to worry about, like making sure that the jobs, logins, passwords, user ids, etc. are kept current on both instances, make sure that you keep your backups straight, etc.