It's still ironic to me that the program that GTK was made for and that popularized the toolkit, haven't managed to move to its latest version yet.
My firsthand knowledge of such things is quite stale nowadays, but I get the impression the RH desktop group is barely on life support at this point. That GTK4 happened at all strikes me as surprising, but could be interesting long-term in terms of modernized GPU support for the toolkit attracting new usage/developers.
The real question is do enough people even care about GTK anymore to make use of it in the future. I'm inclined to believe the current crop of devs want $hipster-language-native GUI packages. Not awkward quasi-"idiomatic" bindings and FFI wrapping an archaic C library like GTK/glib.
re: Gtk4, they're already moving on to Gkt5 (wayland only though https://www.phoronix.com/news/GTK5-Might-Drop-X11).
Looks like a canonical file path (as opposed to dir path) paste handling bug in general, which seems like something worth fixing regardless of one's stance on keyboard paste.
To understand how it's keyboard specific you have to know about what features were removed. In the past you could set the file chooser dialog to have either a text entry field or the path-bar mouse buttons as the default. This was through org.gtk.Settings.FileChooser location-mode. While this gsetting still remains gtkfilechooserwidget.c was changed so it no longer respects those settings and always forces only the mouse based path-bar input mode. This means now when a file path is pasted with ctrl-v (or middle mouse click paste?) the entirely wrong function tries to handle it and this function errors out because it's not expecting file path input.
That is a hell of an ask.
And would it be more work than the gtk2->gtk3 port?
However, what people do not realize about these "toolkit ports", whether within a family (GTK 3->4) or across them (Qt -> GTK), is that the reason they take so long is that it is almost impossible, when having to go through the vast majority of the codebase and change stuff everywhere, to avoid the realization and/or temptation that there are better (or at least different) ways to do things.
If you could suppress that inclination (and its not clear that doing so is a good idea), and simply do as close to a 1:1 replacement where required (which for cross-family ports is everywhere), the port could be a lot faster. But it is extremely hard to resist that, because the non 1:1 replacement stuff just appears so right.