40 mA vs 48 mA is not a big limitation. It's 3 fewer devices on the bus. Except for that, the Mega meets all the IEEE-488 specs so far as I can tell. My biggest concern is I/Os which are only available on certain pins of the Mega. In particular the pins for I2C for the RTC and T&H sensors.
I ignored the Arduino for many years because it targeted non-engineers. But I've developed much greater appreciation for them because they interface well with TTL and are very cheap.
I'm probably going to use two Megas. One to control the RF deck and one to control the DMM deck. The DMM deck will get much heavier use scanning voltage references than the RF deck which will almost exclusively be used for doing cals on the RF gear.
WaveyDipole and I have exchanged some PMs on this. Nothing is decided, but it looks as if I can make what I'm doing fit in to the existing framework. The price of the Keysight and National Instruments interfaces is ridiculous. There is just not that much hardware in them. The Prologix syntax that WaveyDipole copied lends itself to adding "++time", "++temp", "++humid", "++relay in n", etc, very neatly. If it is "#ifdef MEGA" it doesn't break anything if someone is using an Uno.
I'm not looking for someone to do any of what I want. I'm trying to make sure that what I do doesn't break something I don't know about. And as a point of professional pride, when I get done it should be impossible for anyone else to tell what I wrote and what WaveyDipole wrote.
On my first contract job for a major oil company, I wrote a couple of 15KLOC libraries which *never* had a bug reported against them in 12-15 years of deployment. The only change ever made was when Sun released a C standard library which failed to set errno properly after a call to getcwd(3c). That project was a 500KLOC port from VMS to Unix. After the first year of deployment I prepared the release notes. We had under a dozen user submitted bug reports. As we added new programs to the package the bug count went down from there. We had a huge regression test suite that we ran every time we did a build which checked everything we knew to check. After 7 years, a merger in 1999 ended support for the package, but because it was so reliable it ran on until it was simply obsolete.
I ported it to 6 different Unix workstations. I don't know how many it was actually supported on as I left to avoid suffering through the misery of another layoff. The new client had an unannounced layoff the day after I got there.
We had done HP and AIX ports following the initial Intergraph and Sun ports. I did the Ultrix and Irix ports as an afternoon lark one day when I didn't have anything to do. All the business affiliates insisted on buying whatever they wanted. Our policy was, "Yes, sir. We can provide that on any system you choose. You merely need to pay for the 2 weeks of staff time required to verify that the results are correct." The code had two "#ifdef"s, byte order and "RECL=" in words or bytes. Pretty good for a dusty deck FORTRAN port to 6 Unix platforms from VMS. I wrote a program which converted all the VAX run time library calls to functions we wrote using the C standard library in all 500KLOC in a single run. It checked the code out of SCCS, converted it and checked it back in.
There is *no* excuse for buggy software. Buggy production grade software is a clear demonstration of incompetence. Research code is a bit different. But there is a factor of 3-4x difference in the labor required to write research code vs production code. Fred Brooks wrote very eloquently on the topic in "The Mythical Man Month".
But to reiterate, I'm still trying to figure out *what* I'm going to do. And I'm looking for obscure edge cases.