Hi,
Interesting questions. Let me try to answer them in a clear way...
1a) quartus patches are required only if your project uses qspi or serial port as these were modified by us.
1b) the template_bare project is really empty and just contains pinout and a pill. Template_mbox contains a qsys system where the mailbox between Sam and fpga is instantiated. There you can add in qsys your IP blocks and control them using the infrastructure we created (see mailbox and RPC docs under each IP for for reference).
2) the ttf produced by quartus has bits in bytes arrange in the opposite way the FPGA requires them as serialized by the flash. Actually quartus could produce a end file with proper order but it requires post processing as it's not generated at compile time and needs to be converted to text in order to be compiled with the arm application. To summarize, no, quartus does not produce a text file which can be directly compiled and loaded in flash and in any case usually it produces binary files loaded directly by quartus via JTAG.
3) in order create a single binary image we are loading fpga code in a section loaded after the end of Sam d21 flash. This is a trick that allows bossac and bootloader to figure out that the binary file is to be loaded somewhere else, by sending that data to JTAG instead of Sam d21 flash. The idea is that when data exceeding d21 memory is received, that is sent to fpga that writes it to locations of the fpga application space (located after the fpga boot image).
4) fpga flash memory mapped is structured as follows: first 512k are used for fpga boot image, second 512k are used by application image (around 300k are used for fpga binary and the rest for nios application code). The remaining 1mb is going to be used for user applications.. we're actually developing a flash file system to store resources such as fonts, bitmaps, etc.
Hope this clarifies things a bit