In fact there is a real simply solution to this.
Think a bit further and you'll notice.
Let's go.

The problem lies in the fact that once the filter condition is evaluated again by Fox that the variable holding the part of the TO from the filter condition is out of scope.
What you have to do is make the filter evaluate literally and bye bye problems.
Let's put up an example using your code, it will become clear.

>>LPARAMETER mtable, mFilter && mFilter = "table.field = 'value'"
>>>USE mtable IN 0
>>>SELECT mtable
>>>SET FILTER TO mFilter

*-- Correct situation ----
LPARAMETER tcTable, tcFilter && tcFilter = "table.field = 'value'"

local lcFilter, lnCurAlias

m.lnCurAlias = select(0)
USE mtable IN 0
SELECT mtable
m.lcFilter = 'SET FILTER TO ' + tcFilter
*-- evaluate the filter, (have it set, executed)
&lcFilter

select (lnCurAlias)

*----------------------------

If you have a look at the contents of lcFilter it will show something like
"SET FILTER TO table.field = 'value'"
So you have the same behaviour now as if you'd type your filter command from the command window.
The benefit is that Fox will be a lot faster using this technique.
With your idea it had to look up for each record the contents of the variable mFilter to see if the record meets the filter condition.
With my system it only has to check if the record meets the expression.