i've managed to reproduce it

I can also reproduce this. I have changed the fps_max setting to 5 since I think this makes it is easier to reproduce it.
The mouse is no longer captured but the rendering still works, which can be tested by looking at a rotating dropped item or by resizing the window.

I've got this issue when I've stroked "TPHR", which outputs "/tphr". It can also be reproduced by using a macro which presses / and T at the same time.

Can confirm, pressing them at the exact same time will cause the Minetest window to accept no further user input; the game has to be killed through the operating system. In fact I may have accidentally done it once before finding this issue, similiarly to Monniaszia through a chatcommand.

Minetest 5.9.0-dev-be540043e (Linux)
Using LuaJIT 2.1.0-beta3
Built by GCC 12.2
Running on Linux/6.1.0-20-amd64 x86_64
BUILD_TYPE=Release
RUN_IN_PLACE=0
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
STATIC_SHAREDIR="/usr/local/share/minetest"
STATIC_LOCALEDIR="/usr/local/share/locale"

Operating system: Debian 12
Irrlicht Device: X11
Active renderer: OpenGL 4.6

@Montandalar Would you please be so nice to run Minetest (preferably with debug symbols) in gdb, reproduce the issue and press Ctrl+C in the terminal to generate an interrupt? Then get the backtrace of all threads: thread apply all bt. One of them should concern inputs.

EDIT: With setxkbmap us I can press the two keys at once and reproduce this bug. There is no backtrace indicating a stall. It just appears that the input handler is somehow detached.

EDIT 2: The same can be reproduced with T + F10 (chat console). The problem lies in the double GUIChatConsole::openConsole call.