A workaround idea - what is the numeric pin value of BUILTIN_SDCARD for T3.5 and 3.6?
What many people appear to be missing is that the SD Card Socket on the Teensy 3.5 and Teensy 3.6 is connected to an entirely new interface inside the microprocessor from where the SD Cards on prior Teensy products were connected.
The on-board Teensy 3.5/3.6 SD Card Sockets are connected to the micro's SDIO interface logic -- NOT the micro's SPI interface logic.
The new SDIO and the old SPI Interfaces are different and each requires a specific command set to communicate properly.
The old SPI interface was generally a four wire system - Chip Select - CS, Serial Clock - SCk, Master Out / Slave in - MOSI, and Master In / Slave Out - MISI0. Note the SPI interface uses a single bit data line as it clocks data in and out of the connected device. (One Bit transferred per Clock cycle).
The new SDIO interface (as connected to the on-board SD Card Socket) is six wires and can be configured to use FOUR data lines at the same time to transfer data with the connected device. In theory, this allows for faster transfers but requires a significantly different interface driver in the associated library. (Four Bits transferred per Clock cycle)
Several SD Card libraries have been modified to use the new SDIO interface but do so by utilizing unique low level routines to access the SD Card depending on whether they are configured for the SPI or SDIO mode.
Essentially either the USE_SDIO=1 or the BUILTIN_SDCARD parameter is a flag to inform the SD Card library to completely "switch gears" and use a whole new set of low level routines to access the SD Card.
The BUILTIN_SDCARD parameter is NOT just a CS Pin Number.
Unmodified libraries can not "speak SDIO" by simply changing the CS Pin Number.
Great effort has been expended to "hide" the low level details from the user and make the libraries "just work" with either interface by setting a parameter. BUT the user needs to realize that the underlying structures need to be able to "switch modes" for the library to work with the new SDIO interface.
If you application uses libraries that only "speak SPI" then you may wish to consider connecting an external SD Card Socket to the appropriate SPI pins and just push forward until the libraries are updated.
-----------------
PS - The above explanation is slightly simplified.
Almost every pin on the Teensy 3.5 / 3.6 can be connected to serve alternate functions inside the micro via the K66 Signal Multiplexer. The micro pins wired to the on-board micro SD Socket can actually be "connected to" and used as Digital IO, ADC inputs, UART IO, SPI IO, I2C, or SDIO.
So it is POSSIBLE to reconfigure the K66 Signal Multiplexer to connect the on-board micro SD Socket pins to the SPI1 interface in the micro instead of the more common connection to the SDIO interface.
That would solve the SPI vs SDIO problem but the SD Library would still need some serious work to configure, setup, and use the new pins on the SPI1 bus....... (note this involves the SPI1 bus - not the usual SPI bus -- more things to mess with).
The return on investment would push me towards just updating a SPI only SD Library to support use of the new SDIO interface also. This is the solution most developers have adopted with schemes like USE_SDIO=1