Q1: Is there any difference between w:= x-> 1 and w:= (x)-> 1?
Ans: No. If a function has a single parameter, and there's no type declaration (such as (x::algebraic)-> 1), then the parentheses can be omitted.
Q2: Is there any difference between unapply(..., [n, m, x]) and unapply(..., n, m, x)?
Ans: The end results are identical. My guess is that the first of these incurs a very very slight performance penalty, but only in the unapply step itself, not in the final function returned, due to the need to garbage collect the list. My personal preference is unapply(..., (n, m, x)), which indicates to a human reader the logical grouping of the three parameters, but in a purely syntactic way; the unapply command will not even receive these extra parentheses, let alone need to process them. Superfluous parentheses, such as these, are stripped off when the code is saved.
Q3: How to use orthopoly with the uses declaration?
Ans: There are two formal types of "packages": module-based and table-based. Table-based packages are very old, pre-Maple 6 (year 2000), and even most of those have since been converted to module-based, or at least module-compatible. Apparently orthopoly has not. The uses declaration seems to object to this, and perhaps that should be considered a bug. But you can do this:
uses O= orthopoly; #O can be any symbol of your choice.
... O:-H(m, 2^k*x-2*n+1) ...
This is my preferred syntax for any package used within a procedure or module. It involves a little bit more typing, but when someone reads that code in the future, they'll never have any question where H comes from.
By the way, your procedures FunctionA, FunctionB, and FunctionC all have a parameter M which seems to be never used. Surely this is a coding error. I think that you already know that uppercase and lowercase give distinct variable names.
Another error (at least a very likely potential error) is that you need to do something to guarantee that the n, m, and x are of type symbol. The most-appropriate thing would be to make them local to FunctionC, etc.