Please test the above. I am eager to know whether it produces correct results, and, if so, whether it beats a Grid version in real time.

You've edited the Question in such a way that the subsequent discussion makes no sense. In the future, please don't do that. Instead, use a Reply. Editing the Question is fine as long as you maintain the continuity of the subsequent Answers and Replies.

Okay, you now say that you want to remove uncommon factors. Can you be more precise about what makes a factor uncommon? Is it that it appears as a factor in exactly one of the elements of the set/list? Can you give a few more-elaborate examples of input sets (with associated variable sets, if needed) and your desired output from each? In your original example, x+y appears as a factor only once; so why is it not also uncommon?

Salma, this comment is not directed at you, but rather at the instructor who assigned this exercise to you.

This exercise has no practical value! This is the worst Maple exercise that I've ever seen in the 20 or so years that I've been doing this. Occasionally one may write a Maple procedure (or undertake any mathematical endeavor) for its aesthetic rather than its practical value, but, alas, this is also the ugliest Maple exercise that I've ever seen.

@max125 If you edit the Question, that also keeps it active. You don't need to actually change anything; just load it into the editor and resubmit it. This only works for top-level Questions and Posts; it doesn't apply to Answers, Replies, or Comments. 

Regarding deleting; Absolutely do not ever delete or significantly modify anything that has been responded to. To me, that's the rudest possible thing that anyone ever does here.

@Kitonum Please define the "obvious interpretation" that you're using with some degree of mathematical rigor. I'm not trying to give you a hard time; I truly don't see it. Note that the OP said that a, b, and c could be numbers or variables.

Your Answer requires the user to manually pick off a, b, and c for subtraction. If a and x are both variables, how do you distinguish a from x? why not pick off x? And how could your Answer be used if the original polynomials were expanded rather than in `*` form? And what if the set had an element that was simply a? should it be removed?

Also, I'm not trying to criticize the OP for using erroneous terminology. I have no problem with idiosyncratic terminology as long as it can be unambiguously defined.

@Carl Love One would hope that a Threads version would use a smaller real time than a Grid version. Try this:

Coeffs:= (p,v)-> local M, C:= coeffs(p,v,M); table([M]=~[C]):
Indices:= rcurry(indices, nolist):
searchMonomialsEqns:= (
    conds::set(`=`), Eqns::set(`=`), Vars::list(name), poolofeqns::set(set(set))
)->
    if ({Indices}@rcurry(Coeffs, Vars)@expand@(lhs-rhs))~(subs(conds,Eqns)) in poolofeqns
    then conds
    else
    fi
:
ans1:= CodeTools:-Usage(Threads:-Map(
    rcurry(searchMonomialsEqns, {eqns[1..2][]}, vars[2..3], {{op}~(validYZeqnMon)[]}),
    conds5
)):
nops(ans1);

I've tried to capture the entirety of your code in my few lines, but I haven't tested it. If this gives correct results in a shorter real time, I suspect that that's largely due to the one-time set(set(set)) conversion of validYZeqnMon that happens at the end of the rcurry. 

The above should give the same results as this slightly simpler non-threaded code, which uses select instead of map:

InMonomialsEqns:= (
    conds::set(`=`), Eqns::set(`=`), Vars::list(name), poolofeqns::set(set(set))
)->
    ({Indices}@rcurry(Coeffs, Vars)@expand@(lhs-rhs))~(subs(conds,Eqns)) in poolofeqns
:
ans1a:= CodeTools:-Usage(select(
    InMonomialsEqns, conds5, {eqns[1..2][]}, vars[2..3], {{op}~(validYZeqnMon)[]}
)):
evalb(ans1=ans1a);     

@emendes Two small corrections:

1. [M=~C] should be [M]=~[C]. This is needed in case the polynomial has only one term.

2. indices(...) needs to be indices(..., nolist).

I've already made these changes in the code above.

Your example doesn't make sense. Your set has no setwise common factors. If perchance you're interested in pairwise common factors, the only one is x.

[This Reply was based on the first version of this Question, which referred to removing common factors rather than uncommon factors.]

@Preben Alsholm By the way, I think that there's no practical difference between :-Unit and Units:-Unit; the former is directly converted to the latter.

@J F Ogilvie Googling "define: kid" and scanning the first full page of hits, I find not a single dictionary that marks its definition "human child" as crude (or equivalents such as "offensive", etc.), American, or slang. All classify it as "informal". All except one list this as its first definition. The oldest known usage of this definition is from the 1590s, and it hasn't been considered slang since the 1840s.

Unless theta, q, b, and w have some especially simple form, I'm very doubtful that it's mathematically possible to maximize with symbolic sP and sL.

@michele There is a bad habit among newbies to load unnecessary packages in every worksheet, especially plots and LinearAlgebra.

@emendes Commands, such as coeffs, that return values by modifying their arguments are an unfortunate relic of ancient Maple. It's unfortunate for two reasons:

1. It's considered a bad programming practice in any language.
2. Specifically in Maple, it's impossible for a superficial syntax checker to know whether 'M' means a name through which a value will be returned, and thus should probably be local, or a keyword argument, and thus must be global. So, this is why you unfortunately got no warning about this.

To avoid this and other awkwardness with coeffs, I almost always use it with this wrapper:

Coeffs:= (p, v)-> local M, C:= coeffs(p, v, M); table([M]=~[C]): 

Then after T:= Coeffs(p, v), if only the mononials are wanted, they can be extracted as indices(T, nolist).

@max125 It's instantaneous for me also:

CodeTools:-Usage(plot(sin(t/100), t= 0..1000));
memory used=415.18KiB, alloc change=0 bytes, cpu time=0ns, real time=10.00ms, gc time=0ns

If it's not instantaneous for you, try it in a fresh worksheet.
 

@max125 Yes, by using modp, as in this minor update to John Fredsted's procedure:

expMod := proc(pol::polynom(integer,x),p::prime)
   modp(map(y -> lcoeff(y)*x^(ldegree(y) mod p),pol), p):
end proc:

The p in modp stands for positive.