To back up a bit...
You were complaining about the lack of NIS and the different way that the macOS SMB client works. You are using a NetApp server. I have no idea what level of support that product has for SMB, Active Directory, and macOS. Perhaps you should ask them. I'm sure you pay a fair amount for support. Their engineers could tell you more about this than I could.
I can tell you that, even under the best of conditions, with well-run Windows networks, or 100% Mac networks, SMB on the Mac is just flaky. The Finder is flaky too. So if you access your SMB mounts with the Finder or other high-level services (anything other than a straight copy file to or from), you are going to experience even more flakiness. Is it good enough to edit MS Office documents on the server? Sure. You probably won't have to restart your Mac more than once or twice a week with that kind of usage.
But you implied that you were using the SMB network for something more demanding than that, where ownership and permissions are critical. I'm not entirely sure what kind of use you are talking about there.
As far as ownership and permissions go, maybe NetApp can help with that. If not, macOS is going to do what it can do and you aren't going to have much luck getting it to do more. I can verify that permissions are respected. On one occasion I had to make some data read-only because people (Windows users) kept accidentally modifying the data. My account had write privileges to that data but no one else did. Yet my permissions were not sufficient to access some other restricted data that I had no reason to access. So, permissions seemed to work. At least it worked on Sierra. Generally, macOS cross-platform support will get a little bit worse each year.
I cannot confirm that the Mac wouldn't screw up ownership. If anything, I'm pretty confident that the Mac would scramble ownership. Most modern Mac apps that use the document-based API use "atomic writes" to avoid corrupting data with a partial data update. This works by writing to a temp file and swapping the old file for the new one in an atomic operation. I can see how this might trash ownership in a networked environment if the temp file was not created with exactly the same ownership metadata as the original. I'm not saying it does trash ownership. I don't know. But I can see how it could happen.
You also mentioned things like "updated daily", "test data is far too large to fit on one machine", and "networked development". When you say "updated daily", I assume you mean the source, not the test data. That's not an issue. Modern source control system support non-stop updates. I'm not sure what you mean by "networked development". Git was designed for distributed development, which isn't quite the same thing. In Git, everyone has their own local copy of the source. But this is true of most source control systems. What makes Git unique is that the "master" copy only exists in terms of procedural consensus among users. In Git, each copy of the source is its own, self-contained source control system that can be forked into a completely new version, with its own clients and their own copies, at any time.
Git is how source control is done these days. If you aren't using Git, you need to start. Do this today. If you weren't already using Git, using Git will result in better luck recruiting new developers and lower attrition rates.
Regarding test data, there are innumerable ways to get data from here to here. I don't know what you are testing, so I don't know why even flaky SMB wouldn't work. If your system is writing to the test data, then using writeable SMB sounds like a Very Bad Idea. If your data is on the network, you are going to have to get that data to the local machine to test. Why use a flaky SMB protocol, potentially corrupting the test data, when you can just copy the test data locally and run it there? All of the data is on the network. It isn't like you would ever by copying any more data. It's all the same data over the same network. If anything, moving this data data onto another network protocol, maybe with dedicated and/or distributed servers, would really be appreciated by the people trying to use the SMB network for their Word documents. You could use rsync, scp, a local cloud, NFS, HTTP, FTP, SFTP, FTPS, and probably a dozen other funky protocols that were designed specifically for such use.
I don't know what the climate is like at your organization. But from the sound of things, having any excuse to drop the Mac would be appreciated and rewarded, at least in the short term. If you do that, make sure to update your resume. Without iOS support, you might all get laid off. If not, then maybe you never really needed Mac and iOS support to begin with.
