SysML2.0: Webel: Suggest the entire description in the specification of whether and when usages MUST redefine inherited parameters needs an overhaul (and the SysML2.0 spec examples, Annex problem, and SysMLv2 GitHub examples are inconsistent anyway).

Relates to: Relates to the following specification snippets: The issue (such as it may be) is that in some SysMLv2 spec, Annex, and GitHub examples variously:

• ALL parameters (including out parameters) are redefined (yet without feature values) presumably to provide "clean" binding targets as opposed to binding to inherited parameters (although it's not 100% clear whether such is necessary).
• Only in parameters are redefined to provide feature values, but the out parameters are not. (This mode relates also to usages of calculation definitions using parameter syntax where the special result out is not provided.)
• All in parameters are redefined to provide feature values AND the out parameter is redefined (but without a feature value).

Consider for example this extract from the example on p.100 of the SysML2.0 spec: From SysML2.0 p.100:

action providePower : ProvidePower {
    in fuelCmd : FuelCmd;
    action generatePower : GeneratePower {
        in fuelCmd : FuelCmd = providePower::fuelCmd;
        out generatedTorque : Torque;
    }

    flow generatePower.generatedTorque
    to transmitPower.generatedTorque;
    ...

The out generatedTorque has also been redefined, presumably for consistency (since the in fuelCmd is implicitly redefined through the = shorthand) or to provide a "clean" binding target for the flow, or both. But it's not clear that out generatedTorque HAS to be or SHOULD also been redefined,

More relevant examples are tracked here:

The matter relates to the following from KerML1.0, the gist of which for action usages is that you can't simply plonk in a new owned parameter "on-the-fly"; any owned parameter (say x) of an action usage MUST be related to (through redefinition) an existing parameter of action definition (such as feature types the owning usage of the parameter x) or an action usage (such as subsetted by the owning action usage of the parameter x ):