Questions about potential issues setting user shell to non-system or user package

So, I’m migrating away from zsh, primarily due to slow startup times, and I’ve been exploring the other options out there. The two that interest me the most are xonsh and ion shell. but I was curious about a few things…

with xonsh, there is a major issue with actually using it, due to how fedora seperates system python packages from global and user installed python packages via pip. So when xontribs(extensions for xonsh) are installed via xpip(the xonsh wrapper for pip), these packages are unavailable to the shell and cannot be loaded. I posted an issue here, and it’s still being resolved. I’m thinking about simply installing it via pip, more than likely globally using sudo, but would prefer to install it as a normal user if that won’t cause issues(generally better to go with the least amount of privilege that still works)

Ion shell isn’t available as a copr or in the package manager, so installing it from source via cargo is my best bet, my rust installs tend to be user level via the curl one-liner, because of the ability to move between the stable and nightly toolchains for some projects I’m interested in. So more than likely it’s going to be installed belonging to my user.

I was wondering about issues I might run into when using shells that are not part of the system packages or are user based. for example, I know that user environment variables are out of scope when using su, and user configs are ignored in favor of global configs (for packages like ranger) when using sudo, so what happens if I drop into super user using sudo su from a package that is only installed for that particular user.

while I know that python3 integrates both system and pip install packages when importing modules, I wanted to make sure that installing a global pip package, and then setting that to be my shell, won’t cause any permission wierdness or hard to recover failures due to file conflicts.