Well, I just tried workunit item 580125238_12_219839_0 on one of my W7 x64 machines and the client does increment the percentage complete, as elapse time is consumed but its 'chunky' - a few tens of seconds passes then the percentage complete is updated. However, the general trend is that as processing executes, the time to complete also increases. I thought that, maybe, the chunkiness was due to checkpointing so I checked that and found that it still doesn't checkpoint a workunit; I aborted the workunit to liberate compute resources for the much more able client projects I support.
The upshot is that, whilst one could see the irony of the eON 4.x client's search for rarely, if ever, occurring events (like checkpointing) over a very long timescale (eons...) I have to conclude that:
1 - The lack of care and attention to the behaviour of the client software is damaging to the other BOINC projects I run, to contribute towards science; to be clear, I mean 'damaging' in the sense that an open-ended completion time is contrary to the spirit of BOINC and disrespectful of those other projects
2 - With still no checkpointing, and especially now that a client instance of eOn workunit's runtime is potentially unbounded, any restart of the client software as a result of a BOINC framework update or the host machine increases the problem: other projects are denied processor cycles much more due to unnecessary reprocessing of eOn client instances (when these had exeution times up to the handful of minutes, it wasn't a huge problem - still wasteful, but manageable...)
3 - An ironic compounding of the eOn client's tendancy to unbound execution times and no checkpointing occurs, due to the short deadlines set of the eON workunits: the BOINC scheduler attempts to walk the line between deadline, the project level proportions of compute resources that have been set versus the availability of those compute resources - For eOn, this all too often results in a "running at high priority" status being granted to eOn workunits - i.e. maximise the compute resource, at the expense of everything (BOINC projects) else, to conclude these 'expressed' workunits in the shortest time possible, so the deadline is not breached - Irony in bucket loads, given eOn is about testing for events that occur rarely, if ever, over very long intervals of time being 'rushed' by the BOINC scheduler...
Given the above, I'm pulling the plug for my support of this project (detaching) as it seems unable to resolve these types of issues both historically and currently.