Thanks for the responses so far!
Glyn, I appreciate your position, and it is perfectly legitimate, but that doesn’t have to mean that the additional software facilities I suggested ought to be ignored, and I am not demanding them now. You and Trystan don’t have to do all the development and testing by yourself, this entire energy monitoring venture is nothing if not a collaborative one, and has been for years.
I did not ask for nor expect complete common solutions for all gas meters, I suggested that some simple additional flexibility in the software could support a significant enhancement for those gas users who do monitor their meters, and because they are basically generic extensions for pulse-based metering, they may well help with other pulse-based metering, of oil, and water for example. It seems that the primary differential between such systems is the frequency of pulse arrivals, which really determines the resolution of time detail, which might mean that pulse-counting is entirely adequate for high-rate pulsing systems, but with slower rates of pulses, the durations between them could add some useful information. Let the user choose what to do with their pulses.
Also, I am not asking for these enhancements for myself (unless somebody thinks of something I haven’t 
), as I already have working solutions in my system to resolve what I saw as the limitations I listed in my OP. I am not talking about major pieces of work here. Almost all were simple cut-and-pastes of existing functions with some extremely trivial editing, and the only remotely fiddly one was the retrowriting of new Watts to old datapoints, and even that took only about a dozen extra lines of code. The conversion of html and js of the mysolarpv app to turn it into a mydualfuel app again were merely trivial hacks, essentially just re-labelling some displayed titles for the most part.
The real problem I faced was my own ignorance of the coding contexts at almost every level, and I had to do a lot of reading and re-reading, as well as a lot of experiments. You can learn a lot from failure, and I learned a LOT! 
What I am saying here, then, is that you already did all of the real work before I even started, and I just added a few very simple but useful extensions to an already very solid and admirable base. I could not have done what I did without that base, and I am not trying to criticise it.
Robert, actually, I really had no idea how extensive or not gas usage is anywhere, but it certainly isn’t a small sector. And given what Glyn was saying, the percentage who do monitor their gas meters might actually be quite small compared to those who monitor their electricity usage. But those who do may find some aspects of the software a little unhelpful, compared to their electric cousins. Also, I had no issues with how to detect my pulses, there is already plenty of information out there and in here for solving that, and it was not one of the issues I raised. It was what to do with them once I had them that was exercising my mind.
Derek, as I was just saying in my response here, I already have working solutions to my gas monitoring issues as I saw them. They may not be the best examples of coding, but since they were all pretty simple hacks, apart from the retrowriting feed, they do work, and do offer the extra flexibility I wanted. If your gas pulses arrive at similar rates to mine, (highest rate I see is one pulse per 32 seconds, and as long as several hours between pulses, if the CH goes off at night) then a means of deriving the durations between them may give you some extra visibility into your usage.
If you’d like to pursue this, perhaps a fresh post, rather than here?