Proposed, and implemented, some enhancements (1Mb + 1Mb firmware, resizable jsvars size, ...)

I would definetively suggest to leave it there so that it can be compiled directly as an option from the main branch

It's not going anywhere. Perhaps the build_platform_config.py file could be modified to accept 0 JsVars to mean resizable? That way it's an easy tweak.

I understand from your comment that it is not really working in LINUX ?

No, it does work. However Linux can afford to have quite a big chunk size which means that flat strings can usually be allocated.

Regarding "flat string support", do you mean that not everywhere in the code strings are accessed through iterators ?

Usually they are, but if a big area of memory is needed then sometimes it'll be allocated out of a stretch of JsVars. If the block size for resizable jsvars is too small then that may not happen. At least on Linux for things like TLS/HTTPS it won't crash, but the command will fail if a flat string can't be allocated.

Also flat strings are usually allocated for types arrays to speed up accesses - if they can't be allocated then the access speed for arrays will drop right down.

At least a couple of my code changes are bug fixes for the existing LINUX RESIZABLE_JSVARS part and should anyway be applied. What is the best way to get this done?

That's great - if you could create a branch on your GitHub for those fixes and could issue a Pull Request for them that'd be great.

But it helps a great deal to submit changes in several small groups. If something gets broken it's easy enough to look back and see exactly why things were changed then - if it's part of a massive commit you have no idea what changes go with what improvement.

wouldn't this kind of "live" jsvar storage in flash kill it really fast ?

I'm not sure if it's done yet or not, but the idea was that the variable_cache branch would use journalling when writing to flash. The sale way the FlashEEPROM module works at the moment - it's actually pretty kind on flash memory.

Also in my tests I found that the majority of code didn't cause writebacks - most often you're just loading code in to execute, and aren't changing anything so have no need to write to flash.