because JS parser does not know what your php part here may output. It may not output anything at all and JS function call would become loadLeagueTab(current_tab, , current_order) which is syntactically incorrect

Ok, that is a reason. But that nullifies the ability to scan the error column and fix issues because there is always valid code being flagged.
What is worse is this isn't consistent. Just a few lines later this same sort of code is not flagged, why not?

yeah, as long you're using vanilla old php way meaning php is injecting values into html, css or js here and there using <?= echos.
If you try different model where html, js, css are all static and modifying presentation layer in the browser solely in UI based on data returned by the server running php, you'll have no problems like this.


Hmm. I gave it a short test and I could reproduce this problem. Thank you for reporting it. Indeed, all the errors in similar contexts along the file are expected too. In the beginning I though it's parser stopped reporting, something like it failed to recover after 1st syntax error and need more language constructs to recover -- it's known that LALR(1) parsers created with bison or yacc need some tokens (words, identifiers, punctuation marks etc) before they would fully recover. But it fact it's not the case. In my test app that runs parser alone I can see it's posting errors for the other lines. So it's something with sync code between editor and parser. I'll check that.

Followup:
appears that number of errors reported in each particular file, for each particular language in that file, is limited to 3 -- it's concerning PARSE errors only. That's why IDE is showing only first 3 errors in JS and it's clear now why the other lines don't have reported errors. I think it makes sense, otherwise if you miss any single scope limiting curly brace, it will show so many errors. So in most cases you want to fix 1-2 first errors to unblock the others if there is any remained.