Thanks for looking into this, I like this direction a lot more. I haven’t yet looked into all details, but the overall direction looks good to me.
Some data on compile times, max-rss, size-data, and size-bss changed would be nice. (I would hope that the extra indirections when accessing command line options, but one can never be sure…)
It would be good if “Current” would be a different name that is more easily and unambiguously greppable, as such uses indicate global option access that we want to phase out.
We could alternatively also stop adding plugin options to the global option namespace… to me this always seemd to be a weird design that was imposed by llvm::cl only supporting such use. While I added this code to support options in plugins as the easiest way to do so, we could also introduce some -plugin-arg or (probably more preferable?) go for some syntax like -load-pass-plugin=foo.so,-opt,-no-foo. I wouldn’t worry too much about supporting option registration while parsing options.
Not sure I like this bit, this would make it much harder to change the representation. Support options could also be moved elsewhere (I don’t think TableGen depends on Support parts that have options). For TableGen we could also hand-roll a very minimal option parser.
I agree with @MaskRay that we should remove such functionality.
Given it’s uses in clang-tools-extra, polly, Flang, MLIR, Clang, Bolt, it’ll be a long time until we can consider to actually remove llvm::cl.
PS: CommandLineV2 is somewhat of a misnomer, llvm::cl is already version 2, introduced in 2002.