By default KeepassXC can
Would this be still possible with confined users? Could its permission be limited on the last entry?
Also I wonder about other things like automatic detection, this is done purely through the Extension and Native Messaging, right?
Would native messaging work confined, could it be restricted per app?
How does the IPC flatpak permission work here? Does it use the same method?
This depends on what the SELinux flag is. For example ( I can actually test this ) :
sandbox_web_t Will give the application ity’s own X session called Xephyr. Running a password manager that need to talk to browser alone here would not work, as KeepassXC cannot see outside of it’s sandbox. It does use Xephyr so you can interact with it, but it would do nothing. The clipboard would not work either. sandbox -X -w 1920x1080 -H temphome -T tmp -t sandbox_web_t KeePassXC &
Now, you can do a systemd-nspawn container run both your KeePassXC and Firefox inside of it, with similar effect, both applications would be sandboxed, you these relabe the directory you create the sandbox in to have svirt_sandbox_web_t so that the kernel does not bug out. Sometimes container_file_t is used.
As for a confined user, you might have to test that, you could create a directory and relabel everthing in that specific directory.
If the 2 apps are in the same sandbox it should work, but not if 1 is confined and the other is not. This is the effect Flatpak has at the moment, if both are flatpak the native messaging does not work.
xdg-desktop-Portals is supposed to resolve this issue. . . Do not hold your breth for that feature to come to fruition. . .
I am a bit confused 
The end goal (if flatpak allowed browsers to use a different seccomp filter allowing the creation of user namespace containerd) would be both apps as flatpak.
Then the future xdg-portal would take care of that and I imagine the apps could be unconfined?