Much of the historical angst in the forum threads from 6-12 months ago seems to center around two main points of view:
- Arduino = AVR, SPARK is not AVR, QED - and
- Arduino is not professional enough for us; we need to stand up for traditional programming values…
On the first front, with the recent 1.6.x Arduino IDE releases, this is patently untrue. With everything from teensy3’s to ESP8266’s being supported by the Arduino IDE, there is ample proof that SPARK could be fully supported by, and could take full advantage of the Arduino ecosystem.
On the second, I believe that, as crude as it is, and as simplistic as it may feel, it absolutely is the right way to get volume hardware adoption…
I’m a noob Photon user who is also an Arduino library author and model railroad hardware developer who wants to support both worlds.
With my biases out on the table, I’d like to advocate for “Arduino IDE/ecosystem compatibility”. And, yes, I fully realize how difficult it is to adopt NIH technology, how much effort goes into being a follower, and how hard it is to let go of Betamax in favor of VHS… As a mentor of mine once said when talking about the dominant technology in a sector, the difference between being compatible and better and being incompatible but better is that of standing on a giant’s shoulders or having them step on you…
On the library front, to make things concrete, is there a downside to simply adopting the “Arduino 1.5 library standard”? (https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification)
As I see it, there would be some mechanical changes to the build.io code, and the uber-library-example: spark.json becomes library.properties, the directory structure changes a slight bit, but the result is simplified support for many different boards and architectures by the original library author - and no need to fork and maintain SPARK-only copies of everyone else’s library.
The same could be said for the firmware HAL core itself, but this is the library forum 
-John