Uml Activity Diagram Join Vs Merge

I have the following simple activity diagram:

Simple AD with object flows

My problem / question about is the last activity and its incoming object flows:

how to model proper UML here?

In UML-Spec 2.5.1 I find these quotes:

[15.2.3.1 Activities]

An object token is a container for a value that flows over ObjectFlow edges [...]. An object token with no value in it is called a null token. [...] Each token is distinct from any other, even if it contains the same value as another.

[15.2.3.4 Object Flows]

Object tokens pass over ObjectFlows, carrying data through an Activity via their values, or carrying no data (null tokens). A null token can still be passed along an ObjectFlow and used like any other token.

[15.3.3.5 Merge Nodes]

A MergeNode is a control node that brings together multiple flows without synchronization. [...] if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows

[16.2.3.3 Pins]

The multiplicity bounds on a Pin constrain the total number of values that may be input or output by a single execution of an Action, not the number of tokens it contains (see the upperBound property inherited from ObjectNode). A Pin may hold null tokens that contain no values. [...] An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin.

[16.2.3.4 Actions and Pins in Activities]

Executing an Action in an Activity requires all of its InputPins to be offered all necessary tokens, as specified by their minimum multiplicity (except for the special cases of ActionInputPins and ValuePins, as discussed above).

I understand it that way, that my model is currently wrong - because it is impossible to have both object G as input due to the decision before.

So I have to reduce the object flows to 1 to succeed.

That seems to give me these options:

set multiplicity to zero
- but multiplicity is on value, not on token, so a token would be required to flow in
- I just don't create even a null token in B if I decide for A
use a separate merge for the object flow
- simply said: my modeling tool does not allow an object flow to an object or action pin
- could be a bug

Then there is more in spec:

[15.4.3.3. Central Buffer Nodes]

[...] It accepts all object tokens offered to it on all incoming flows, which are then held by the node. Held object tokens are offered to outgoing flows [...]. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting object node, as for any object node.

Well, sounds like a way out: any input is accepted and the moment an output is accepted, it is done.

Problem smaller:

my modeling tool now offers only Dependency, Trace and Information Flow (2) - no object flow to the receiving Action Pin. All I could get is an object flow (1) to the related action. Which misses the visualization - might it be necessary because an action pin is unable to accept a token?

same AD with central buffer node