Ray
I'm not sure why we'd need to make a duplicate / new class for SPI with an additional function.
This sounds like it would cause maintenance issues.
I guess we could subclass the existing SPI class with a new SPI class that had an additional function e.g SPIDMATransfer() and also doesn't auto instantiate
I presume its possible to inherit a class from another library class (I think this is what the ILI9341 lib does with the graphics lib)
But I don't see any problems with adding a new function to the existing class
The only issue with the existing class is that it does the Auto Instantiation, which wastes ram if you are not actually using SPI1
I've already come across the same auto instantiation issue with the Wire library. I needed slow the I2C transfer down to communicate with the OV7670 camera, so I had to instantiate another copy of the Wire library, but passing the slow speed param into the constructor (as fast is the default)
(umm thinking about it, I'm not sure if there is a call to set the speed, but I dont think so... I will need to check)
Having to instantiate 2 copies (one auto instantiated) wasted a few hundred bytes of ram, which isn't ideal, but I can live with it.
Personally I'd have preferred if all the libs didn't auto instantiate , as I'm far more used to doing something like this every time I need an instance of a library object
Wire myWire = new Wire(FLAST_SPEED);
But I think that if we changed this for the SPI library, lots of people would complain that existing examples and libraries that used SPI no longer worked ;-(
PS. Looks like my workload is dropping off, as I've just finished a website and also just submitted an App to Apple for review (so fingers crossed it doesnt get rejected for some bizarre reason 
)
So I may be able to get back to looking at all this lovely new code later today or tomorrow 