TYPO3 Core

The bad guy can be found between lines 2303 and 2335 of class.tslib_fe.php

No pageOverlay is found and therefor a switch is used to choose from
sys_language_mode

*strict: Shows an Error Message
doesn't matter in this case - no content gets shown

*content_fallback: Uses another language for the content, when available
doesn't matter either and will show a maximum of 2 different languages at
once, while leaving sys_language_uid as is
The latter makes sure that pi_getLL and other stuff like i.e. HMENU will
work with the same language, because sys_language_uid and config.language
are triggered by the same TypoScript condition. Content elements in other
languages than config.language will be seen on purpose, because this is the
desired behaviour set by the admin.

*ignore: Leaves sys_language_uid as is
doesn't matter in this case - see above

*default: Sets both, sys_language_uid and sys_language_content, to 0
It seems default is the bad guy here, since page and content will be set to
ID 0 while, the rest of the system will still work with the language set in
config.language regardless of the TypoScript condition.

Since default is the only case, that will cause unwanted behaviour, I guess
it will be enough to check for sys_language_uid or sys_language_content
being > 0 and sys_language_mode being false in any place that is currently
using config.language only.

Well - the FE localization guide clearly states, that

"any TypoScript conditions (for example [globalVar = GP:L=1]) are still
effective so any settings there are kept regardless of the localization
mode"

So at a first glance, the behaviour with &L=1 without having a translated
page at hand seems to be correct, because the TypoScript we used contains
(adapted to the languages used in the manual)

config.sys_language_uid = 0
config.language = en

[globalVar = GP:L=1]

config.sys_language_uid = 1
config.language = dk

[global]

But at a second glance the behvaiour does not match the listed "Result",
which says (adapted to our case):
Content => English
Menu => English

A plugin IS a content element and in this case it is using danish labels,
because it is triggered by the TS condition only, which generates
config.language = dk

So IMHO the manual is misleading and the behaviour unwanted.