The C3 runtime hasn't shipped enabled by default in a stable release yet - we're aiming to finish all relevant documentation by the time we do (hopefully in the next few weeks).
By testing it I see it definately cleans out image memory in the debugger, but so did a certain plugin for C2 that couldn't fix construct's real memory issue: cleaning out the cache ram storage for unneeded assets.
The C2 runtime kept compressed images in memory even when they weren't loaded. (I think we discussed this previously by email some time ago.) As part of the rearchitecting of the C3 runtime, we fixed this: images that are not used, are not loaded in to memory at all. The only exception to this is that the HTML5 export saves downloaded assets so it doesn't have to download them again during the game, however such assets are not loaded in any way. The browser might keep them in memory as an optimisation, but it is free to dump them to disk if necessary. The "offline" export options that bundle assets with the app (e.g. NW.js & Cordova) don't make any effort at all to save assets because it doesn't need to download them, so they will definitely have improved memory characteristics over the C2 runtime. For a large project the difference could be significant.
When I load images from URL onto a sprite, delete the object, unload and recreate the object. I see that the loaded URL images is still present. I figure this is because the asset was never really unloaded from the cache? Can someone confirm this is the case, or link me to some documentation?
Sprite's "Load image from URL" essentially overwrites a frame in the animation, and the animation is stored per object type, so all instances share the same frames. (This is true in both runtimes.) I'm not sure we tested how unloading memory interacts with loading from a URL - if it's not working like you expect please file an issue and we'll take a look.