I just found a much more shorter (and much more general and dangerous!) version of code, which demonstrates this bug:
1) Create new worksheet.
2) Enter and execute formula below:
> F(-1/3);
F(-1/3)
3) Execute it again (or execute the entire worksheet) - minus sign will be lost:
F(1/3)
I can't believe, that after 3rd update we still have so unreliable code :(

Now I analyse the code of "eval/diff". When I will be ready, I present some examples...
Ok. I finished code review and can present 2 examples, when eval, applied to diff, works not as simple subs:
eval(diff(f(x, y), x), x = y);
eval(diff(f(x, y), x), y = x);
I also found simple solution of my problem: it is sufficient execute command:
constants:=constants,H;
and after that
eval(diff(f(x),x),x=H)
isn't evaluated to df(H)/dH.
May be it is more proper to slightly change eval/diff code, to allow using
assume(H,constant)
with the same result.
Thank you!
-andy-

But I still don't agree with that (see help:eval).
-andy-

Because it doesn't require additional tuning of Maple. Thank you.
-andy-

Thank you, now i'll try to find error there. This is really important, especially after I found example (see my new thread also):
eval(diff(v(x,y),x,y),{x=H,y=H})
which produces very strange result..
-andy-

Command
>print(`eval/diff`);
returns line (both in Linux and Windows)
proc(e,eq1) ... end proc
May be, you already have redefined eval/diff proc?
-andy-
P.S. simplest form of eval/diff (which produces mathematically correct result) is:

> `eval/diff`:=proc(f,subseq)
eval(convert(f,D),subseq)
end proc:

:)

Below is the quote from Maple help about "eval":
The eval command knows how to __correctly evaluate derivatives__, integrals, piecewise function definitions, etc. whereas the subs command in comparison makes substitutions which may not make sense mathematically.
Do you agree, that "premature" substitution isn't mathematically correct?
If there are symbolic dependencies between the expression and the point at which it should be evaluated that are considered ``unsafe'', eval will return unevaluated.
I think, that "my" case should be definitely marked as "unsafe".
This knowledge is coded in the Maple library in the Maple procedures `eval/diff`, `eval/int`, `eval/piecewise`, etc. The user may teach Maple how to evaluate a function as follows. Given a function foo(y), the call eval(foo(y),x=a) will result in `eval/foo`(foo(y),x=a); being called if the user has defined `eval/foo` to be a Maple procedure.
I am not a profi in Maple programming, but if source code of "eval/diff" is available, the problem, I hope, could be solved.
-andy-

Using quotes is impossible, when eval(..) is a result of previous calculations.
About using "D"... Of course, if this strange functionality isn't a bug, but a feature, you are absolutely right.
But functional syntax isn't so obvious and simple as diff. It uses integer subscripts, not symbols. You can't change only the order of function arguments, or add new argument at the beginning of the list, but need also to change D[1]->D[2] etc.
I think also, that two ways (D and diff) should be equivalent...
-andy-