The idea is good, the format itself is terrible.
I have to agree. Five major versions of it and counting (no attempt to cull older versions to reduce complexity), multiple compression algorithms (including gimmicks like RLE), SHA1 for some reason, a huge amount of code that's mostly tied into MAME rather than being fully independent, etc.
If a CUE is included, it would take 2-3 minutes for an emulator that can play IMG/SUB files (or even just BIN/CUE files) to support my proposed BCD format. If the CUE is omitted, make it 5-10 minutes to include a simple parser.
Nobody in MAME cares about optical formats
Last I read, their position seemed to be, "since we can't optically record every pit and landing, ISO/BIN is good enough."
What are you going to do with non-zero bytes in R-W area on non-CD+G discs?
CD+G discs must be ripped from drives that can read subchannel data. Multiple reads, preferably from multiple discs and multiple drives, should be done to reduce errors as much as possible. Unfortunately, there's no guaranteed way to read it because the CD-ROM standard designers stupidly didn't include the subchannel bytes inside the C1/C2 error codes. RS(25,29)+RS(29,33) instead of RS(24,28)+RS(28,32)+SUBCODE would have made this all a non-issue.
Auto-generating missing data is a *last resort* desperation move, and we would need to go out of our way to make it as clear as possible this was done. I'd even go so far as to add an intentionally bad W-channel string in the first TOC sector to identify the data as being faked.
Ideally, we want the officially ripped data. But, I mean, good luck getting redump.org to start over again to go back and rip the lead-in and lead-out sections on the few drives that can even do that.
The only reason to have a tool to fake the data is so that emudevs only have to support one format, and it will automatically run good, complete image rips when available.