My main gripe with a shell like Fish is that it won't work with the trusted ol' BASH scripts. Seeing as I deal with quite some BASH scripts on a day-to-day basis at work this keeps me from trying it out, even though I'd love to be able to use something more sophisticated/evolved than plain BASH.
My main gripe with 'BASH scripts' is that in most cases they could simply be 'Shell scripts' and in most cases they call and require Bash for no reason at all ;)
I guess most people cannot be bothered to remember which features are bash specific and which will work in any /bin/sh. I don't think there is such a thing as a generic "shell script", csh has completely different syntax.
There's just a couple tricky ones in these scenarios.
For me, there's virtualenv and rvm that both mess with shell stuff deeply enough to where running them in fish can be tricky.
virtualenv has good fish support, but never really got rvm working. I ended up going back to zsh after 2 years or so in fish because of small issues like that and realising that so long as I had reverse search I wasn't really gaining much in productivity from fish.
In my terminal I usually have several tabs opened by default in fish, but have another open to the python repl, and sometimes bash if I need something. Easy enough to do.
Imho "source" is an anti-feature. I think instead of "source", you always should create a subshell. It properly encapsulates your modified environment and avoids leakage and confusion. Exiting an environment is a straighforward exit/<ctrl>-D like with any shell. You do not need to remember a special "deactivate" command like with virtualenv.
I swear by subshells. They solve so many problems. People object that they don't let you do environment autoloading on `cd`, though (which I also hate, so... Yeah).
