@freitagbr can you also give thoughts on this section?

My concerns:

• it's weird that cmdOptions is 2 different types. Maybe we can use {} to signal "no options"
• unix is an awful property name. I'm not even sure this functionality should be exposed publicly.
• We should fail loudly during plugin registration an unknown plugin-option is used.
  • Also fail loudly for bad values (e.g. globStart: true)
  • Also fail loudly for invalid combos (e.g. globStart: 2 with allowGlobbing: false)
• We should consider auto-generating this table from in-line documentation (this would require moving it to the README, but I don't think this needs to block release).

Nice, I like this change.

Regarding the wiki section:

• For cmdOptions, using a boolean usually indicates that true and false are both accepted values. In the case of cmdOptions, passing true doesn't really make sense. Perhaps null would be a better fit here. Or, as you mentioned, and empty object. Also, are we trying to distinguish between "ignoring any flags passed" and "not allowing any flags to be passed"? null and {} might indicate the latter, but not passing cmdOptions at all might indicate the former.
• Yeah, unix isn't super descriptive, and it sounds like we don't remember its purpose. I would err on the side of removing it, we can always add it later in a minor update.
• Yeah, failing loudly is a good thing to do for plugin instantiation.
• I agree, the documentation should be auto-generated, just like the other APIs.

Also, regarding the overWrite option: maybe an error should be thrown instead of just overwriting the previous command. i.e. If Bob is trying to register his git over Alice's git, he should probably just remove Alice's git from his code.

Closed in favor of #812