For example, MSVC link.exe doesn't have --start-group and --end-group options because their symbol resolution semantics are different than Unix.
Yes, but this is specific for a linker, not for a target. For example, GNU ld supports this option for all binary formats. A linker with universal CLI would then
support this flag for all targets as well (or drop the support for all targets if recursive dependency resolution can be implemented without that flag).
link.exe on the other hand doesn't have --init or --fini options because that's ELF-only concept.
Yes, so a universal CLI would hide this flag when linking non-ELF binaries, as well as any other option not supported by the target currently linking for.
(This is not the same as using a separate flavour for that target.)
Linker scripts exist only in GNU.
My reasoning is the same as for `start-group'. In fact, lld does not achieve feature parity with GNU ld configured for mach-o here:
the latter can use scripts when linking a mach-o binary, but lld cannot use scripts at all unless GNU flavor is used, and then mach-o is
Also, I think if we try to create a unified interface, I guess it would end up with this situation -- https://xkcd.com/927/. We have three standards -- GNU, Darwin and MSVC. I don't know if we want another one.
This depends on whether the flavoured CLIs are removed upon merge. (Of course, it is probably impractical to remove them all at once.)
In my opinion, GNU ld has CLI closest to my description, so it is a good basis for a universal interface. In fact, GNU flavour can be universal if support
for more targets is added there, but then the other flavours will likely be redundant. One difference would be that a universal CLI need not maintain compatibility
with GNU ld CLI.