Will not willingly upload MusicXML and MXL files

Where did you get that file from, how has been generated, which program?

See also How to fix a score that contains corruptions

The software that generated this .musicxml is apparently called "Flat", the source is https://flat.io/score/5ea059b9d902a04ad64ee6f3-inkwell-isle-world-one

The score is indeed very corrupt, it has 12 instruments, 10 of which are entirely empty, no time signature, no key signature, no rests (!), nothing.
From the remaining 2 instruments the 2nd is partly corrupt, no rests.

I guess that is due to the fact that this file is just a single line of 1721823 characters length, no further formatting at all. It seems at a certain point (2nd staff, measure 29) MuseScore stops reading it.

MuseScore loads it though, no hang or 'complete halt'

I guess so, yes. An entire score in just a single line is not going to work in any application that tries to read the file line by line and has a reasonable limit for a line length.
Report this problem to flat.

The attached file loads OK for me in 3.x, all versions of (desktop) MuseScore I tried (3.4.2, 3.5.1 and 3.6.2) fail. A debug build reports ASSERT: "_e.isEndElement() && _e.name() == "notations"" in file .../MuseScore/importexport/musicxml/importmxmlpass2.cpp, line 6188.

This is the MusicXML parser getting out of sync due to missing whitespace. I couldn't quickly find the issue number, but I do remember fixing it. Apparently the fix hasn't made it into a 3.6.x release yet.

Running the MusicXML file through an XML formatter fixes the issue, see attachment.

This is the same issue as #315904: [MusicXML import] incomplete import from ScoreScan XML file. As that has already been merged into 3.x (on Sun Feb 7 09:32:34 2021 +0100), a new 3.x release will automatically fix this issue.

Note that the parser used by MuseScore (for MusicXML parsing) is not affected by the single large line. The lack of line breaks only makes viewing and editing very difficult.

That fix is in 3.6.2 already , like the 5th to last commit before release, it is even mentioned in the release notes.

More likely #317098: [MusicXML import] check code for white space issues?

The original score opens corrupt in 3.6.2, the one with whitespace opens cleanly

A 3.x development build of mine (3.x branch plus some 36 more commits on top) does open that file cleanly though, so I wonder which of the issues mentioned in https://github.com/musescore/MuseScore/issues/7449 might have fixed it?

Ah, I see: #319210: MusicXML import detect corrupted file when the file is minified
That indeed got merged post-3.6.2 and would be in a 3.6.3 if there ever will be one (none is planned)
It would be in 4.0 too though (it is in the master branch already)

And here's the imported score

Perhaps I mixed up two issues, as they are related.
#315904: [MusicXML import] incomplete import from ScoreScan XML file
#317098: [MusicXML import] check code for white space issues

317098 is a larger problem, as the same issue is present at multiple locations in the importer, while 315904 is one specific instance.

Using my debug builds, 3.6.2 aborts on the Inkwell file (which would result in an incomplete and corrupt import using a production build) but 3.x imports that file without problems. The fix thus has been merged after 3.6.2.

The fix for #319210: MusicXML import detect corrupted file when the file is minified fixed the crash here, and indeed got merged after 3.6.2 got released. The one for #315904: [MusicXML import] incomplete import from ScoreScan XML file is in 3.6.2, but doesn't help here.

That score indeed does have <ornaments><inverted-mordent/></ornaments>, an empty (inverted) mordent tag, exactly the thing the fix for #319210: MusicXML import detect corrupted file when the file is minified fixed