Quote "I'm not saying *this* problem is due to running out of RAM. I'm just saying that even if this issue is resolved, there's no reason to expect CHDK or the Canon firmware to run indefinitely."
The S50 has run for many months straight w/o fail (between scheduled PDNs for maintenance) with RemoteCapture no problem, ie 20,000+ images in a row, now for years without a single failure. That's good design and I see no reason why fundamentally the newer higher-end PowerShots should be worse. Of course you're not piping image data direct to USB yet so it could be different as you point out, but, from the *feel* that I am getting from my experiments of the last 2 weeks, I know if you implemented write detect, the solution would work. I think you must also realize that with me you have a very respectable test base for your solutions. Likewise, I am getting high performance liveview with your app and a pretty good prospect for fail-proof performance on the camera side. I'd say take advantage of my contributions while my activity related to this upgrade is still hot.
Quote "Canon design requirements: Run a few hours / few hundred pictures at time. "
I disagree. Since the S50 many years ago, they supported RemoteCapture. RemoteCapture = indefinite shooting as I just demonstrated to you. Thus no memory leaks or accumulating open file handles.
Quote "If there is some subtle issue that crops up after a few thousand shot cycles, would they have any reason to fix it?"
Absolutely yes ... hundreds of millions of cameras that they cannot afford any bad press especially where it can be easily controlled, and the competition is fierce from all angles. Good software engineering requires the building of exercise and simulation code that accelerates usage and shakes out the bugs. I am convinced Canon engineering does exactly that, something I myself did in the 80's-90's for a terrestrial radio systems modeling tool & GIS I designed for the local electricity utility's maintenance vehicles. Canon's reputation is on the line. For example, I followed your heap manager output in the DOS window with great interest and was delighted to see that nothing (neither Canon nor CHDK) was chewing up memory. Consistent .... if that had been a problem with the S50 for example, it would have failed incessantly. Proof-in-pudding.
Quote "Again, the point was not that you will run into that particular issue, it's an illustration of that fact that Canon doesn't design for more than a few thousand shots in a session."
My experience pushes me to disagree vehemently. S50: hundreds of thousands of shots to date without a single failure, RAW & JPEG.
Quote "That doesn't change the fact that CHDK is dirty hack,"
For a "dirty hack" it seems to work exceptionally well already. We can get it as good as Canon and I will demonstrate the results.
Quote "To the first order, that would require actually doing it, so no."

Quote "Wasting your time trying to optimize the delay is entirely your own choice."
You still don't understand ... optimizing the delay has two very independent and equally important objectives:
1) to make good use of the high speed SD writes and USB 2.0 data transfer rates, and
2) determine if delay has a cut-off where FAILs no longer happen.
#1 will be thoroughly tested once I move the S90 to the instrumentation bench. #2 has priority at this stage and can be worked out on the test bench. If I am forced to stay with the delay hack, then for #2 I don't yet have a satisfactory answer. At 750 ms or less, it fails under 50 myshoots. At 1s it failed at ~900 myshoots. Since last night I changed the value to 1.2s and this morning it's running at ~975 myshoots, still very far from a satisfactory answer. You've spent many years developing CHDK. Consider these few weeks my contribution to the verification of your work. Please understand that I have to do this because you don't have write detect implemented. If you have other priorities, then take advantage of my work rather than telling me I am wasting my time, and, please don't let me lose respect for you by repeating me this to me.
@microfunguy
Quote "Describe in detail what your experiment is and what the instrumentation is required to do."
Once I see very convincing results on the instrumentation bench I will touch base with you. I have a sense you might like what this project is all about. Keep in mind that the instrumentation is fully developed and functional. Moving its primary imager from the S50 to S90 is strictly an upgrade and there is no design involved at all. I don't know if you've been following my comments early on, but I can tell you this: S90+CHDK will result in at least 9 f-stops low-light performance improvement over the S50. Huge. That's the bottom line.
Quote "I may know of suitable equipment."
Thank you for your offer. The basic requirement is the following:
) CCD sensor surface no larger than 1/1.7" and no smaller than 1/2.3"
) Maximum pixels possible with these restrictions ..
) no more than 10 mpx (1/1.7"),
) no more than 8 mpx (1/2.3"),
) 1/1.7" 10 mpx is optimal
) RGB, not monochrome
) Signal processor: Correlated double sampler, low noise wide dynamic range VGA
) min 12-bit ADC depth, max 14 bit
) Space less than 6 cu in
If you can come up with something that is better in low-light performance than the S90 at room temperature, I would call it a miracle. I am interested in your thoughts.
Quote "At the very least it would save reyalp spending an absurd amount of time on an exceptionally specialised project whose requirements are somewhat vague."
The global requirements of the instrumentation are exceedingly complex. The requirements of the imager are simple, stated above. Both those are independent of remote control operational requirement, which I am sure you would agree is generic. So, regardless of any specialised (and distant) requirements for the equipment, CHDKPTP liveview clarity has been fixed, UI overlay has been fixed, palette has been fixed, aspect ratio problems have been fixed, a flexible programmatic shoot command has been implemented, RC image transfer implemented (for JPG, CananRAW & CHDKRAW, all tested), and CHDK heap manager has been fixed, at least for S90, SX110 & siblings. Get an S90 or SX110 and try remote control ... it did not work just 3 weeks ago and now it's amazing // you'll be hooked. I would like to see write detect implemented as a final request to test robust industrial-strength performance, which I feel your CHDK "dirty hack" is capable of. From another perspective, I think my exceptionally specialised project covers a vast field of very demanding digital photography at the grass roots level, not bells and whistles, that I am offering you. By your and reyalp's accounts however ... I am beginning to wonder ... is all you've done just for my project? Maybe it's true. Please tell me ... if so, I would rather respectfully bow out of my efforts to improve your software. Do let me know.