Yes, regarding locks it starts going down the rabbit hole real quick. The simplest thing to start with would be to synchronize with the remote drive while nobody's looking / file handles are closed / have expired. 

The original idea is have something that for the most part feels like a thumb drive to the end used and mounts on linux and windows machines without further ado. I've had my share of fun with libusb filter drivers for AVR programming dongles and windows driver signing. That's what ultimately kept me from venturing deeper into learning how to write drivers.

On the other hand I had some fun using LUFA (USB stack for USB enabled ATMega32u4 and the like) to implement a primitive "sound card" device that allows recording an accelerometer data audio stream. That really made me appreciate generic USB classes.

So my design principle would be to avoid unnecessary complications and I embrace the limitations of the generic driver support forcing me to stick to it.

Hehe sounds like a fun way around the issue. Hopefully I can explore that in due time. 

Awesome project idea.  I can think of many times it would be useful.  Instead of a mass storage device, you might consider exposing the storage as a MTP device.  (see http://www.howtogeek.com/192732/android-usb-connections-explained-mtp-ptp-and-usb-mass-storage/)

Thanks for the comment. You made a point there. I'm still using Windows a lot and I've felt the differences without putting a name to it. 

MTP would be tempting to use for best storage efficiency at the cost of transfer times and the least hassle with different OS. 

On the other hand it would be nice to transfer the files ahead of time and just have them appear on a mass storage device linke an rsync backup. Thinking of it, that might get out of hand depending on file sizes, taking minutes at a time and blocking access to other remote files.

If multiple device endpoints are possible without much of a hassle I can imagine the device presenting as a media device and mass storage device at the same time, with complete access on demand through MTP and folder oriented download on access via the mass storage device. 

MTP will be sufficient for most cases however I like the idea of executing binaries and opening different formats with the proper file associations. Just a matter of convenience though.

If you go the mass storage route, one thing to consider is that only one device can access it at a time (filesystem drivers don't take kindly to the bits changing unexpectedly underneath them).  MTP should handle that fine, as it's basically a filesystem-level interface.  But, as you noted, it comes with its own painful restrictions.  I'm curious-- you didn't state it, but it seems that you probably have an implicit requirement for not having any drivers.  i.e. just plug it in and it works.  Is that so?  The reason I ask is that you can probably get the rest of the features you want if you were to add a custom driver, but it does seem to be getting away from the beautiful simplicity of your original concept.

Are there even MTP gadget drivers for the pi or would that need developing / porting? 

I've not seen any guides on how to set that up. 

I'm pretty sure with MTP both hosts can write to the filesystem at the same time.  

Not something that says PI on the package but https://www.archlinux.org/packages/?name=libmtp 

won't be having much time to play around this week but maybe that's something that I can spend some time on researching

edit: wrong. "libmtp is an Initiator implementation" 

then what we'd need is an MTP responder... https://msdn.microsoft.com/en-us/library/jj584948(v=winembedded.70).aspx

see, I really need to read up on that ^^

Theye guys from the past didn't get anywhere as it seems

http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/how-to-support-mtp-responder-media-transfer-protocol-on-an-embedded-linux-4175425567/

encouraging! My only hope is that all these incomplete implementations have fallen prey to some android-ish singularity that replaced them with one official library.