Here is another (tentative) kind of workaround,

restart;
unprotect(apply);
apply:=proc(p) p(_rest); end proc:
protect(apply);
with(VectorCalculus):
assume(x::real);
assume(y::real);
D[1]((x,y)->x^2-y^2);
(x, y) -> 2*x
D[2]((x,y)->x^2-y^2);
(x, y) -> -2*y
D(x->sin(x^2));
(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*.

kernelopts(version);
Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895
showstat(apply);
apply := proc(p)
1 p(args[2 .. nargs])
end proc
apply(Typesetting:-Typeset, sin(x)):
#lprint(%);
# 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.

kernelopts(version);
Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701
showstat(apply);
apply := proc(p)
local P;
1 eval(subs(P = p,P(args[2 .. nargs])))
end proc
apply(Typesetting:-Typeset, sin(x)):
lprint(%);
Typesetting:-mrow(Typesetting:-mi("sin", fontstyle = "normal"),
Typesetting:-mo(""),
Typesetting:-mfenced(Typesetting:-mi("x")))

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.