If the extended SPI library is used with the Due for hardware CS, it appears that the state of the CS pin must be INPUT. This is opposite then other Arduino boards where pin 10 had to be OUTPUT. See the following examples. This should be documented, or ideally the extended SPI.begin() function should set the mode of the CS pin to INPUT. If hardware CS is not used, the program would set the pin used for CS to OUTPUT, so having SPI.begin() set the mode would ensure it's set properly and avoid a common problem when switching from software CS to hardware CS.

If the pin mode for the CS pin is never set by the program, the hardware CS signal works.

For the record, I am using two thermocouple boards from Adafruit to take measurements from two thermocouples, I am using SPI, everything works fine. To setup SPI I followed this:http://arduino.cc/en/Reference/DueExtendedSPI

For simple SPI access there's no need to worry about the pinMode. For more advanced applications where you need to disable the SPI module and control the pins directly, the pinMode setting matters when you return to normal SPI mode.

I think this bug might be more serious than it first appears. Looking at the pinout diagram, Arduino pin 10 is connected to two different pins on the SAM3X, port pin C29 and A28. pinMode(10,OUTPUT) sets C29 as output and sets it high. But SPI.begin(10) would cause the SPI hardware to use A28, and drive it low when needed.

So I'd conject that pin 10 is not actually floating, but when the CS is selected it is being driven both high and low at the same time

Adding pinMode(_pin,INPUT); to the beginning of the SPIClass::begin(uint8_t _pin) method ought to solve the problem.