For the reasons previously discussed in my post, I'd prefer to keep worker proposals paid in SBD, but it would only moderately increase the complexity of the system to support both. In such a case, the simplest implementation would be to have a separate pool of funds for SBD proposals and Steem proposals, with SBD proposals competing for SBD and Steem proposals competing for the Steem. A more complicated system would allow for some automated conversion between the two coins and all the proposals would compete with each other, regardless of the coin they were denominated in. In general, I prefer the simplest possible initial implementation without Steem proposals and leave it open to later improvements if it seems warranted.
I do agree with your concern about SBD price pumping causing potential problems, but I'd prefer to see implementation of the Steem->SBD conversion solution previously discussed as a method of stabilizing the price of SBD relative to USD.
I'm actually pretty neutral on where the source of the automated funding comes from. I suppose as written in appears that I'm favoring adding a new source of "inflation", but I'm actually completely comfortable with it coming in part, or in full, from one of the existing sources of inflation and I've been operating on the assumption that different people would propose reallocations from different existing sources as well.
On the naming issue, I would be fine changing the name. For the initial discussion, I felt it best to keep in the terms used by BitShares, as this would allow the greatest clarity for the reasonable size community of Steem users who are familiar with how it works and for people who want to take a look at how the BitShares system currently operates. But for long-term external marketing, I don't have any strong preferences for how it is described and probably some A/B testing should be used.
As @yabamatt noted, the SBD pumping issue can be handled outside of the core mechanism anyway. Proposals can be made to sell the SBD instead of burning it. This requires a bit more trust than funding directly to @null but that is true of the entire mechanism. So I have withdrawn that suggestion.
Although this seems to be off the table and not needed, I don't think it would be very hard to: a) keep the fund in STEEM, b) make the optional conversion from STEEM to SBD at time of payout based on a property of the worker. I.e. the same way content rewards currently work. The refund worker would be required to be STEEM-denominated in this model.
Yep, ultimately I think that would end up describing my second "slightly more complicated option".