Typically, if a mounted USB is pulled, the mounted filesystem will become unreadable and unwritable. The state of the filesystem on the USB may also be corrupt if there are unwritten dirty pages in ram. (A fsck might fix this, but there may also be data loss.)
When you plug a usb back in in this state, it will be mapped to a new device name, without the ability to reconnect the old mount. The only resolution here is to unmount the broken mount and remount from the new device name. (The old device name may disappear as soon as it is unmounted, making the name available for the next USB plugged in.)
However, since this is the root filesystem, you can't unmount it and remount it (since it is in use), so this becomes an unrecoverable situation. This is of course fatal, but not instantly.
Things still cached in ram will still be readable for a while until their cached page is evicted and then it will also be unreadable.
You won't be able to run new programs (not already cached in memory) at all. Even the directory they were in becomes unreadable, so you'll get "Command not found" for almost everything.
Existing programs that need pages not in memory will likely crash and suddenly die without warning and possibly without visible error.
Some things (like possibly your shell) might never crash, as they are in memory and in use, but won't be able to do much as everything else will be broken.
If you are in a GUI, parts of the GUI may die as they discover missing pages they needed, including the terminal windows holding your shells, and they may just disappear when you try to type in the window, or the whole GUI may eventually crash, dropping you into a text terminal (which you won't be able to log in from since everything is broken).
Critical system services that have things open on the failed root mount will not function properly even if they don't crash, so things will get progressively worse.
If you happened to have a root shell open, you might be able to remount the recovered usb over top of the existing broken root mount, but likely this won't be allowed, and even if it is allowed, it won't fix programs running from the old mount that already half crashed, and some programs running with the old mount won't see the new mount and will still be stuck.
When your last remaining shell crashes (without any error or way to record the error), nothing will be able to replace it, so it may appear to just become unresponsive and seem lock up when it really just died silently.
This is an unrecoverable state that will get worse as you poke at it until everything crashes and you reboot.
You won't even be able to shut down or run the reboot command, as this triggers services to try to shut down cleanly (although it is too late for that).
The only sane recovery is to reboot. It will require a hard reboot, which if you are lucky can be done with the command reboot -f -f but likely that will be unavailable and you will have to do the equivalent manually by holding the power button until it turns off. (If you enabled sysreq keys, you can do the equivalent with AltSysRqb which will always work (if it is enabled).)