Here is another (tentative) kind of workaround,
apply:=proc(p) p(_rest); end proc:
(x, y) -> 2*x
(x, y) -> -2*y
(x) -> 2*x*cos(x^2)
What happened between Maple 2015.2 and Maple 2016.0 was that apply was changed. Here it is in Maple 2015.2. I'll note that it had issues dealing with procs with special-evaluation rules.
Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895
apply := proc(p)
1 p(args[2 .. nargs])
# wrong result omitted by me
And here it is in Maple 2016.0. It handles that particular spec-eval-rules example, but it can go awry on some examples with assumed names.
Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701
apply := proc(p)
1 eval(subs(P = p,P(args[2 .. nargs])))
Typesetting:-mrow(Typesetting:-mi("sin", fontstyle = "normal"),
That implementation of apply in Maple 2016 goes wrong as used in VectorCalculus:-D under certain assumptions. (That use relates to my earlier Comment in this thread where I examined the addressof certain variables under those assumptions.)
The implementation for apply shown in the workaround above also handles that particular spec-eval-rules example, but doesn't break as used by VectorCalculus:-D under the assumptions in the original example. Ie, apply:=proc(p) p(_rest); end proc .
I should mention that I do not know how this alternative definition for apply would fare under a full regression test suite run. So I'm not going to advise anyone stick it in an initialization file.
I could also mention that I doubt that any purely Library-side implementation of apply can mimic special-evaluation-rules perfectly. Using apply already involves one full evaluation of the extra arguments, since it does not have spec-eval-rules for any extra parameters. The eval(subs(...)) approach in Maple 2016 adds yet another evaluation, so it looks more suspect. Consider the example apply(sin, ''2.1''), which returns sin('2.1') in Maple 2015.2 and also with my tentative apply implementation, but which returns a float like 0.863... in Maple 2016.2.
note. From the ?paramprocessing help page, "Like evaln, uneval can only be used for required positional parameters. It also cannot be used in conjunction with any other modifiers, or in a parameter declaration after one with the seq modifier." So putting spec-eval-rules on all extra parameters in a Library-side implementation of apply seems problematic.