@tolot Assuming we're only talking about Base MPP... In your first scenario:

     B    E  
A ->   ->   -> G -> D
     C    F

h0   h1   h2   h3  h4

NodeD creates an invoice and signals support for base_mpp. NodeA creates two HTLCs using the same payment hash in NodeD's invoice for each HTLC. HTLC-1 is routed B->E->G->D and HTLC-2 is routed C->F->G->D. Remember, only NodeD knows the preimage for this invoice.

NodeA sends both HTLCs at the same time, but they arrive at NodeD at slightly different times. NodeD gets the first HTLC and they have the preimage to redeem it, but they also know that there is a second HTLC incoming. They don't want to redeem HTLC-1 until they have HTLC-2 also. If they did prematurely redeem it, then they would have to reveal the preimage to NodeG who is also responsible for forwarding HTLC-2 and NodeG could use that same preimage to prematurely redeem HTLC-2 without actually forwarding it to NodeD.

Once NodeD has both HTLCs, they can safely redeem both of them by revealing the preimage to NodeG, etc.

Your second senario would happen in a similar way:

         B     E  
A -> I ->   ->    -> G -> D
          C     F

h0   h1   h2   h3    h4   h5

I think the confusion lies in this statement: "meaning two HTLCs flowing in the same channel for the first hop, then splitting and the riconverging."

The HTLC's don't "split" and "recombine". They are two seperate HTLCs. Its just like making two separate payments that happen to use some different hops and some of the same hops. Only the receiver has to worry about "combining" these HTLCs into a single payment.

Every LN channel has a limit to the number of "in-flight" HTLCs allowed on that channel. The default is 400+ HTLCs so most nodes should have no problem holding two HTLCs. It does not matter that those HTLCs happen to have the same payment hash (preimage).