Thanks, Ian; very helpful. I also just read through http://ghc.haskell.org/trac/ghc/ticket/3658 — I had incorrectly assumed the DynamicByDefault page subsumed it. That helped me understand people's concerns a lot better. Here's my updated status.
I'm deciding between
* Solution 1 — using the rts/Globals.c mechanism for `FastString.string_table`, or
* Solution 2 — requiring a dynamically-linked ghc to (safely) use plugins that involve FastStrings.
I prefer Solution 1, because
* it handles any number of instances of libHSghc in a process, *regardless of how they got there*, and
* it puts no constraints on the rest of the user's installation — use whatever kind of ghc you like.
I have one remaining concern: in the eventuality in which ghci becomes its own dynamically-linked binary and ghc remains statically-linked, then my patch will be the only remaining use of the `rts/Globals.c` mechanism. (For the record, that mechanism is vastly simpler than the RTS linker…)
We can cross that bridge if/when we come to it, though.
I'm planning to push Solution 1 to HEAD this weekend, unless someone shouts at me politely.