Most likely Dropbox needs to set these limits so that they can allocate their quality assurance department to very thoroughly test what they claim they support.

I'm an architect for a Dropbox competitor. Sometimes we need to draw a line in the sand for what we support, and what we don't support. This is mostly due to balancing cost / benefit. A customer may do something strange that we don't support, and we have to weigh how many engineering resources it will take to support the customer. This can apply to unusual filesystems that we don't actively test our product with.

IMO, Dropbox did the right thing. It's only real technical users who get into different kinds of filesystems; and these are the same kind of users who can understand, "Dropbox only works on X, Y, and Z."

From a QA point you're actually right. I don't think Dropbox needs to support all filesystems, but as a programmer and and advocate of better user experience, I'd like to see a system which behaves a little differently:

a- FS is something we support, great! Go on... b- FS is an unsupported one, so run the tests and if they pass warn the user: "Hey! We don't support this, but it looks like working. If it fails we can not support you. Are you sure? (Y/N)" c- FS is an unsupported one, so run the tests and if they fail tell the user: "Hey! We can not work on this FS, sorry.".

The good thing is you implement the tests once. Since, POSIX standard is a standard, so run the tests over that interface. You practically don't need to maintain anything about the tests. Maybe run a couple of unit tests over a simulated environment, that's all.