On the other hand, we already have all kinds of conditions on the leg. But I agree, we should have an additional step in the booking phase, to demand showing the terms&conditions.

How about this:
extend the enumeration in the planningStep (v.1.5): SHOW_TERMS_CONDITIONS
and extend the condition object with the description to show to the end user.

condition:
  type: object
  properties:
     + userText:
           description: text describing this condition, to show to the end user in the offer phase. Booking the leg with this condition
              implicitly means accepting this condition.
           type: string

My understanding is that the terms&conditions need at least to be read and approved by the end user immediately before the booking is triggered. So e.g. in the app there is a "booking" button which reads "by booking this service you adhere to the terms&conditions of the TO".

So at this time point when the terms&conditions need to be made available for the end user there doesn't exist a booking yet. If there is a booking - independent of it's state - the end user has already agreed to the terms&conditions.

To me that sounds like showing the terms&conditions is not a booking step because there is no booking yet. So it should be part of the planningStep:

planningStep:
    type: object
    description: this action allows to publish advertisements together with the proposed leg.
    allOf:
    - $ref: "#/components/schemas/information"
    - type: object
      properties:
        action:
          type: string
          description: the `RESULT_SHOWN` action requires the MP to display some information to the customer when it is viewing the proposed legs.
          enum: [  SHOW_TERMS_CONDITION, RESULT_SHOWN ]

I think the existing action "RESULT_SHOWN" has a more informative character but doesn't include contractual relevant information. And the info should be displayed when viewing the leg. In the case of the terms&conditions they must not necessarily be shown when viewing the leg but when booking it.

What if the MP wants to book legs with different TOs for an intermodal trip? Then the end user will presented multiple terms&conditions and he needs to approve all of them at once. But that is then the job of the MP to coordinate this.

Regarding your last point: completely agree. It's up to them how to cope with that. But the option to show (and agree) the terms & conditions is part of the booking process. Otherwise, the end user should be confronted with the T&Cs of each option. Maybe it should be a mix of both:
In the planning phase, there should be the SHOW_TERM_CONDITIONS, including your first proposal. Secondly, there should be an additional condition: agreedOnTermsAndConditionsCondition (name to be discussed), to highlight that the SHOW_TERMS_CONDITION is not allowed to be skipped.

So, in short:

Information - enum: [INSTRUCTIONS, SALES, TERMS_CONDITIONS]
planningStep - enum: [  SHOW_TERMS_CONDITION, RESULT_SHOWN ]
+ new condition subclass to indicate to highlight that this step is a real condition

On the other hand, making use of 3 concepts is complicated. Let's discuss next meeting!

@matt-wirtz :I've pick up this issue, added the enum value 'SHOW_TERMS_CONDITIONS' to the planningStep. The real question is, where the MP can find the T&C? In the booking object (also used in the offers, we do have the userCommunications-array. In this array we can supply Information objects. Depending on the configuration in there, the text of the T&C can be found (url or text). Together with your proposal to extend the 'goal' enum with 'TERMS_CONDITIONS', this looks doable to me.

At carsharing.link the consent to TO's terms is a required step within booking. It is the responibility of the MP to do that properly.
However we are thinking about solutions to provide the TO with the possibility of any kind of confirmation. Maybe some hash/signature of the content+consent as response value....

And there are ideas to make the system more universal.
With Edwin I've already discussed the idea of standardization and modularity (textblocks)....
Another idea is to make the consent system unviversal to use it for other actions as well. E.g. required vehicle check in preparing-phase, or some kind of confirmation on the end... 🤔