SYSML17 — DirectedFeature is confusing

The intended use for the <<DirectedFeature>> stereotype is not at all clear from its specification in section 9.3.2.4 in SysML 1.5. To be clear, the current description describes what it is, but not why it is required, or how a modeller might use it. Moreover, it is not clear whether it specifically applies to ports (since its part of the section that specifies the language facilities for ports and flows (section 9), or whether it relates to features (properties?) of a block that are not ports.

The issue was discussed at the RTF meeting of 2017-10-12 as a result of discussing issue http://issues.omg.org/browse/SYSML16-108. There was little consensus on what DirectedFeature is, although Conrad suggested the following (being my interpretation of what was said):
A DirectedFeature of a block describes whether the block implements that feature (it's "provided") or that the feature is represents a conceptually virtualised feature as an "assumption" that something else in the model will provide it. The fulfilment of the required assumption with an actually provided realisation of that feature is by a connector between the required and the provided features.

The problem with this interpretation is that it seems to have nothing to do with ports! There is of course further scope for confusion with the UML notation of provided and required interfaces on UML ports.
At the very least, some examples that clearly illustrate what problem DirectedFeature solves and the types of model elements that it is to be applied to would help a lot.

Improved description of DirectedFeature

The description in SysML 1.6 has improved quite considerably. However it can be further improved by slightly modifying the way the corresponding text is structured and by clarifying that any feature are implicitly "provided" if no DirectedFeature stereotype is applied