Shall the behaviour of an included use-case always be executed with the behavior of the including case?

Consider a use-case UC1 that includes UC2 and UC3. The UML 2.5.1 specifications define «include» between two use-cases:

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase).
(...)
All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

I understand that the behaviors of UC2 and UC3 are always executed with UC1, in view of the affirmative wording of the include definition, which implies systematicity and leaves no room for conditionality ("is inserted into", "is executed"), whereas the extend definition explicitly mentions a non mandatory possibility ("can be inserted into", "behavior that should be added, possibly conditionally", see also section 5.1 of the specs about the use of CAN and MAY).

I wonder if my interpretation is too strict. So does the inclusion:

• mean that whenever UC1 is performed, the behavior of both UC2 and UC3 is always executed, i.e. with the expected observable results for the actors or other stakeholders?
• Or is it possible that the behavior of one of the use-cases, say UC2, is not always executed? And why would this understanding be compliant with the specs?

There are two possible scenarios in which the behavior of the included use case is not executed:

Precondition in included use case is not met

Suppose UC1 has precondition User must be authenticated, and the user is not yet authenticated. In that case the UC1 would not execute.

Single location of execution of include is not reached

The specs mention a single location where the included use case is executed. Now we all know that a use case does not necesarrily follow a single sequence of steps. Although use case scenarios are not explicitly mentioned in the UML specs, it is common to have a main scenario, and possibly a number of alternate and exception scenarios.

Depending on the circumstances, some or steps in the use case will not be reached, possibly because an alternate scenario path is followed, or maybe because the include location is in an exception path that is not followed this execution.

In those cases I think it is perfectly within the specs to say that the included use case is executed only under certain conditions (i.e. actually reaching that point of execution)

In this example of the scenarios a use case Update Reservation expressed as an Activity Diagram, we see that we only need to execute the use case Update Inventory in the alternate scenario Cancel Reservation

This could have been expressed more clearly in the UML specs.