The point of using a unified ABC processor like BarFly is that you can play the tunes and view them with the same application.

What you're doing is using the so-called "ABC 2.0" stuff that Gonzato and Moine invented. It's directed to using ABC as a typesetting notation with Moine's "abcm2ps" program - it doesn't represent music any more, it represents notations for notating music, and it's application-specific - only abcm2ps understands it. Pointless. There are plenty of other and better music typesetters out there.

I don't mind trying to make something more more portable, but I will need to see the orginals to do it. I literally can't do anything with the ABCs you've provided, since I have no idea what they are trying to say - it would be easier to start afresh. But I'd need access to your sources.

There is no need to retain old and ambiguous usage for accidentals - if you can work out what they mean, modern conventions can represent the same information, and you can always include editorial notes in the header if something is irresolvably confusing.

This is really muddled:

The primary intent of my P-directive usage is to be able to repeat or silence these various sections by simply altering the P directive in the header.

You don't get to decide what "P:" means. Its meaning was agreed more than 15 years ago. Nobody seems to implement it correctly for multi-voice music (BarFly gets it horribly wrong) but having users invent their own semantics based on empirical experimentation with their favourite program certainly isn't going to make it any more implementable.

I have never seen the point of MIDIs. I don't use them at all. Since a properly written ABC can give you the same sound with more options (you can choose tempo, instrument etc) and also give you staff notation, why keep the MIDI hanging around? - it's purely an output format, you don't store it.