I recall our conversation, but I can't find our old email exchange (I recently had to restore my system, lost a big chunk of emails). I definitely like what you've done with it; I was originally designing this one as an L-R parser after reviewing the functionality in YACC/LEX, Bison, Gold Parser, etc., solutions. Then I ran across Irony and decided it provided the simplest method of implementing an LALR grammar/lexer/parser. L-R parsing is a little less efficient than LALR, but for a grammar this simple and considering the simplicity of most search strings users will provide, I don't think it's going to be noticeable to any degree.
Another nice thing about the Irony functionality is the grammar is easily extended to encompass more functionality (like recognizing mathematical expressions, etc.) I was working on adding some of that type of functionality at one point, but got sidetracked on other projects.
If you wrapped your function in a SQL CLR function wrapper you could create the query string server-side and use the DMVs/DMFs locally to eliminate stopwords from the query. You could even execute the query locally using the context connection. Might still be less efficient than a more optimized native solution like the one you've requested, but for simple solutions like these the performance difference will probably be negligible.
Another alternative might be to read the entire stoplist from SQL Server in advance and persist it in memory locally. That way you can eliminate the burden of supplying another stoplist to the function - also the issue of keeping it in sync with the stoplist on the server.