Using aaronp's sdl_test I got the following results on arch using gnome3:
After seeing the cursor pressing and holding "down arrow",
approximately 5 seconds later single press of space while still holding "down arrow"
and keeping "down arrow" pressed for around 5 seconds and quitting with esc while still holding it down.

So using no repeat actually releases the key even before pressing space , I am confused...
But seeing this now I remembered using Linux Multimedia Studio music software (also using SDL1)
The piano roll can be played with the keyboard, and when holding a note (with enabled key repeat), it will release by its own and start repeating the key.

The repeats while holding a note there are:
8000ms / 13000ms / 13400ms / 14500ms / 16300ms
This will continue in a seemingly random fashion

But turning off key repeat in gnome3 works ok for LMMS , but not for dosbox.
Could this be a broken key repeat detection ?
Have to check how this is handled using wayland and its XWayland compatibility layer.
EDIT: Scratch that, on my system my dosbox build under wayland gets almost NO KEYS, as in 1 keystroke of 100... so better not explore this any further 😊

I just compiled and tested DOSBox with SDL2 support and it fixed random KeyUp events in at least one of the titles I experience the problem (Megarace 2). It also fixed DOSBox alt-tab behaviour and I think mouse movement in-game feels more native (I need to properly test this though).

DosFreak, nice 😀 hopefully you'll be able to bisect the change. In the meantime I made my copy of TR1 work without the need for SDL_sound, so I could test input in SDL2 build - with the same result: input worked correctly in fullscreen, in SDL2-based build. Then I tried openglide (SDL1) - and input issue came back (but was harder to trigger). In the process I found out, that SDL2_sound library appeared in 2018, but never reached releasable-state - tried SDL2 build + SDL2_sound, but it crashes in TR1 (works with other games, but e.g. ogg decoding is a bit borked).

I had the same problem for at least two years now. I also concluded some things:

It only happens in Linux: Any BSD or Windows works fine. I used to have FreeBSD just for DosBox
I also concluded it is a bug on SDL1.2

I couldn't solve without removing SDL1.2, so I had to compile DosBox-X. That let me compile directly with SDL2 and not lose imgmount capabilities. In any case DosBox has a lingering and annoying bug on this, at least under Linux

Erm a stupid question of mine, Autolock function is off?
If not it could be the case that if you pressed a key longer as three seconds you will release the autolock function, shut that tard off to play games with the keyboard.
The Problem is most probably not rooted in DOSBox.

Exactly Doom well, a young friend of mine played it not long ago, he likes FPS games a lot and he's somewhat to young to know Doom.
He stumbled very soon over this issue which i fixed to his surprise by simply disabling the autolock function.

I won't claim that this is the solution, but often it's a quite simple one and often not related to the emulator you run.

Always guess only our new OS' assume things you never will like.
They call it "intelligent" i call it stupidity.
Just because 51% of users use it in a certain way it won't mean that it is intelligent if i assume this.

Besides, i still never played Doom for real, he played it through but i like the music mostly 😀

@Gernot66 The problem is rooted in using SDL 1.2, which is unmaintained since 2013. Some Linux distributions are starting to drop SDL 1.2 from the repositories because almost whole open source world moved on to SDL2, DOSBox is one of very few stragglers.

Just dropped in to contribute my similar experiences in GODS while running distribution-specific packages of Dosbox in both latest Arch Linux and Mint 19.3. The spartan becomes unresponsive while a directional movement key is being pressed. I needed to release and press the key again.

EDIT : Installing the SDL2 version (dosbox-sdl2 SVN) from AUR repo in Arch solves this problem.