@mdma @peekay123 Sorry for being thick headed.
I interpret ‘system firmware’ differently than C / C++ libraries. I totally expect that a call to Spark.connect() will reference the code located in the firmware. But, for example if Spark.connect() calls the C function socket() then will the call in my user application to socket() reference the same C function located in the firmware or will the linker include the code for socket() from the system C library into my user app?
@mtnscott, I am not sure I would consider “socket” a fundamental C function but it’s definition is part of the Core firmware communications library. I would hope (and expect) that any functions defined and/or used in the firmware AND called in the user code would be referenced and not duplicated.
This is a good, and very valid question, and the answer hasn’t yet been decided.
There are two main routes:
The first approach would allow sharing of common C/C++ library functions that are used, while the second generally won’t support sharing. (Although some functions must specifically be made part of the dynamic link interface for the system to work e.g. malloc/free.)
We’ve not yet made a decision about which approach we will use, so comments welcome! 
@mdma, I am so glad Spark hired you 
My only comment would be in regards to what is kind of new on the Photon and that is FreeRTOS. I need to do my research on this but in an ideal world, the user could create threads and not just use setup() and loop(). In that case, as long as the fundamental FreeRTOS “api” can be exposed via dynamic links then I am with option 2.
Option 1 creates the same situation we have now where user code that worked before and is recompiled no longer works due to firmware changes. In a true production environment, the firmware and user code are kept separate and individually controlled. 
#1 gets my vote!!
I would like as much flash space as what can be possibly be made available.
I have a project that uses an LCD display for sensor data and have already run out of flash. I wanted to add graphics and the touch screen driver for the LCD so I could have multiple screens of data but I can't so it will have to wait for the Photon. Graphics can take a lot of space - the more flash available the nicer I can make my interface (adding icons for example).
The Spark is, and Photon will be, very powerful cores. As soon as you put a graphic display on them IMO - they need more flash.
At the end of the day - the level of sophistication of the projects you can do with the Spark platform will be limited by the amount of flash available for the user application.
I’m using a 2.8" TFT 320x240 display w/TouchScreen I purchased for $12 from BuyDisplay. It uses the ILI9341 controller. I build with the following libraries - Adafruit_mfGFX_IDE, Adafruit_ILI9341 I also purchased the font chip on the display but have not yet figured out how to use the fonts on that chip, so I am using the fonts you built into the nfGFX_IDE library.
I do have the option of installing a 128MB flash chip on the display and writing the drivers for reading / writing that flash so I could put my icons and data on it for enhancing the graphic user experience, but it would be much much easier to have the data available as part of my app - not to mention easier to port to another LCD display.
@mtnscott, I understand your dilemma and using SPI-based flash or a font chip means slower screen refreshes since you have to read the font bitmap data via SPI and then write it out again via SPI. If refresh rates are not a major issue, it is very feasible with a customized ILI9341 driver. I did something similar for a large Sharp LCD using an FRAM.
I also used a 4D Systems display where multiple screens, graphics and animations were required but at a higher cost. They are easy to configure and only require a single serial port to work.
Thanks for your kind words @peekay123 
Totally agree about exposing some of the new RTOS features via the HAL, if it’s not exposed via direct linking.
Ahah, I just remembered, I concluded recently have to go with #2 - dynamic linking, since we have to support factory reset. This means the system firmware must be compatible with at least 2 user firmware images, which rules out using static linker tables.
@mtnscott - the amount of space saved with static linking I imagine to be marginal compared to other methods, and I wouldn’t let space taken due to duplicated libs be the deciding factor. For example, we are looking at 128k or possibly 256k for user firmware - if you drop factory backup, then that could potentially be increased to 512k. Early days, but seems feasible on paper. But if that doesn’t transpire or turn out to be a workable solution for you, then adding the 128k flash to your lcd display would be a good choice.
Yes, that makes sense. Oh well, it will still be much better then the current situation.
@mdma, that sounds about right. The trick will be to expose all key functions through the HAL. I agree that there will be a negligible price to pay for duplicate libs and it is unlikely that the firmware will use hogs like sprintf that would benefit from single instancing.
What will be interesting are the features that FreeRTOS will bring such are true low power support, real multi-tasking and peripheral abstraction. So many new toys! 
Can’t wait to get my hands on a photon!