I have this issue too.

Sometimes, MSUpload POST to the API, but without any "action" parameter, only "name" and "file", like this:

-----------------------------xxx
Content-Disposition: form-data; name="name"

<File name of the current upload>
-----------------------------xxx
Content-Disposition: form-data; name="file"
Content-Type: image/png

<Binary data of the current upload>

Since there is no action, that API will return the documentation in HTML format instead.
MSUpload can't handle non-JSON responses, so it will throw "Error: unknown error".

After the error if I'm not mistaken, sometimes MSUpload will retry the failed upload.
It will correctly send the "action" param this time along with the "file" of the previous file.
BUT (this is the important part!), somehow it will also merge the request with the snippet above.
Both "name" and (another) "file" param is based on the next file.

Something like this:

-----------------------------xxx
Content-Disposition: form-data; name="filename"

<File name of the previous error upload>
-----------------------------xxx
Content-Disposition: form-data; name="action"

upload
-----------------------------xxx
Content-Disposition: form-data; name="file"
Content-Type: image/png

<Binary data of the previous error upload>
-----------------------------xxx
Content-Disposition: form-data; name="name"

<File name of the next file>
-----------------------------xxx
Content-Disposition: form-data; name="file"
Content-Type: image/png

<Binary data of the next file>

"Name" param is not needed by the upload API, and only the last binary data is taken.
The result: Binary data of the next file + file name of the previous error upload.

When there are 2 files, A and B, probably A is not uploaded, and B is uploaded with A filename.
Or, A is uploaded, and B will be uploaded again replacing the A file. The filename is off by one file sequentially.

But when there are more files, let's say A, B, C, D, E, and encountered are a lot of errors,
It's even possible that E will be uploaded using A filename.

Does this still occur?

Yes, still occur.

I’d also reported this upstream suspecting an issue with the extension itself: https://phabricator.wikimedia.org/T311484

So the problem will never be solved?

Hopefully