NME was sort of the original pioneer in being a Haxe library designed for desktop and mobile application support. The design of NME is primarily C++, with Haxe wrapping it to provide support for each native target. It by and large follows the Flash API, with some departures and some added features.
I was one of the lead developers of NME, Lime and OpenFL are sort of an extension of that work, but it takes a different approach.
Lime is designed to be used either by people who prefer to work lower-level (such as direct OpenGL calls) or to be used underneath a framework such as OpenFL. Most people can use OpenFL quickly and easily, but OpenFL benefits from the stability and portability of the Lime codebase.
The Lime legacy path originates from NME. This is the default currently for native OpenFL builds. Lime itself does not use this code at all, but the OpenFL “v2” code accesses it to render and generally behave in a similar way to NME, but unified with OpenFL’s other targets.
Otherwise, Lime is totally distinct. Lime creates a window, provides system events (such as mouse, keyboard and touch input) and provides access to rendering and sound, not only for desktop or mobile targets, but for HTML5, Flash and console targets (which is in the works). Over the Lime API, everything is consistent, besides the rendering, which is (by necessity) different between, say, canvas and OpenGL.
When you use the -Dnext flag, or when you use the Flash, HTML5 or upcoming console target, OpenFL is 100% Haxe code, written over the top of Lime. OpenFL used to have distinct HTML5 and native “backends”, but over Lime it is all unified now. I use “-Dnext” in order to allow both the older code and the new code to develop in tandem, heading toward the day when we switch entirely. If you wanted to develop a cocos2d-haxe library, it might be simplest to adapt to Lime (which is OpenAL + OpenGL on native) than OpenFL (which is the Flash API) but you can mix-and-match too.
