I don't understand that at all.
The hardware [between AVR and SAM] is quite different, so if a library is using the [AVR] hardware it will not be "functional" [on the SAM hardware].
I was pointing out that the library could have the same name and methods, but the implementation has to change on the different platforms. It's basically a re-write, but the SAM interface was defined by the existing AVR library. A re-write can act differently in subtle ways.
Sometimes, the code has to be changed (ported), not because the AVR and SAM have different peripherals ("hardware"), but because the C/C++ environment is slightly different. That library would not run on the Due, but not because is was using "the hardware".
For example, a library that doesn't use any peripherals may have code that depends on
sizeof(int) or pointer alignment requirements. It would not be functional, even though it compiles.
Specifically, which libraries are you saying don't work on the 3.1?
Heh heh, the ones that you really want. Seriously, though... I claim nothing specific about all libraries, just that you have to approach the term "compatible" with a healthy does of skepticism, and either try it yourself, or see what the Teensy community has reported.
I have used a lot of different peripherals (RTC, DS18B20, audio board, uSD cards etc.)
Hmm, I use the term "peripherals" to refer to the autonomous blocks within the MCU chip: UART, SPI, I2C, PWM, etc. You have been able to those "external modules" because the "peripheral" libraries were re-written for the SAM hardware: somebody re-wrote the HardwareSerial class, the SPI library, etc. The RTC library is portable enough that it could function with the SAM I2C library and the AVR I2C library.