Inverse interop with aioquic packet reception issue

[The3ternum]

I am currently trying to perform a multipath connection between a modified aioquic server and a pquic client, and I have a question: Does the pquic multipath plugin allow for multiple sending uniflows to send data to the same IP address? whilst also sending from a different port?

I'll give a short example:
For testing purposes, I provide an aioquic server with multiple addresses: "::1:4433", "::1:4444" and "::1:4455" (same IP, different port)
I also run your pquic client with the multipath plugin enabled (same as in previous cases)
I then connect the client with IP address "::1:XXXX" to the aioquic server on IP address "::1:4433"
Will the aioquic server then be able to send data from two separate uniflows?
They are bound to the following 4-tuples:
("::1:4433" to "::1:XXXX")
("::1:4455" to "::1:XXXX")
(Notice that the client address is the same)

The reasoning behind this question is that it seems like the PQUIC client stops responding to the aioquic server after receiving stream data.

1. The handshake completes normally, and the client sends mp_new_connection_ids along with add_address frames to the server.

2. The server then creates the context for two additional sending uniflows, and binds them to the same destination IP address of the client, while having a different source IP address from the server (The 2 tuples seen above).

3. The client is able to parse the two path challenges that are received from the server directly after sending those frames, and responds accordingly with a path response twice over its initial uniflow (one for each path challenge, see the "challenge and accept.png" screenshot below).
   One Note: the client does seem to log an event named "peer_address_changed", but i am not sure about its meaning.
   

4. The server then starts to send stream data to the client: 3 1-RTT packets containing Stream 0 data over uniflow 0, and a number of 1-RTT packets, also containing stream 0 data over uniflows 1 and 2.

However, the client only logs the reception of all the packets sent over uniflow 0, and only the first two packets that are sent over uniflow 1, no packets are received from uniflow 2 (see the "stop responding.png" screenshot below).

I can't seem to figure out why the client just stops responding after receiving the two packets from uniflow 1. The client never
sends back an ack regarding packets that carry stream frames.

I have included the QLogs from the aioquic server (AMPs_large.qlog) and the PQUIC client (PMPc_large.qlog), as well as the PQUIC client console log (PMPc_large.txt) in Logs.zip

I have also heavily modified the PMPc_large.qlog file, due to it not generating correctly:
-translated all "onertt"-packet_types to "1rtt".
-Added "configuration": {"time_offset": 0, "time_units": "us"}, "common_fields": {"group_id": "1", "ODCID": "1", "reference_time": XXXXXXXX}, "event_fields": ["relative_time", "category", "event_type", "trigger", "context", "data"] to the end of the qlog, since they were not added upon closing the connection.
-changed "reference_time" from XXXXXXXX to the same reference time as the aioquic qlog-value, which is 1609341639759941.
-changed some packet numbers to be able to identify which uniflow is sending the data (100000+ is uniflow 1, 200000+ is uniflow 2).

It is also important to note that the console log of the PQUIC client doesn't reflect these modifications. At the end of the log the client receives two packets with sequence values 1 and 2, these are respectively the two packets that are received from uniflow 1, and should match the packet number values of 100001 and 100002.