The full evaluation performed by 'eval' is described in ?eval > Description:

The call eval(e) means the expression e is fully evaluated up to two delayed evaluations (see uneval). This means that each name in e will be evaluated to its value, and the value will be evaluated recursively, and each function call in e will be executed with its parameters evaluated, but not beyond two levels of delayed evaluations.

So,

a:=2:
eval('a'),eval(''a'');

                                 2, a

The full evaluation performed by 'eval' is described in ?eval > Description:

The call eval(e) means the expression e is fully evaluated up to two delayed evaluations (see uneval). This means that each name in e will be evaluated to its value, and the value will be evaluated recursively, and each function call in e will be executed with its parameters evaluated, but not beyond two levels of delayed evaluations.

So,

a:=2:
eval('a'),eval(''a'');

                                 2, a

Yes, as type 'sqrt' is defined in ?type/sqrt, both these subexpressions:

indets(f3,sqrt);
                            1              1/2
                       {----------, (x - y)   }
                               1/2
                        (x - y)

are selected and replaced by 'g'.

However, I am not convinced that such designed behavior, i.e.

type(1/sqrt(x),sqrt);
                                 true

is fine.

Yes, as type 'sqrt' is defined in ?type/sqrt, both these subexpressions:

indets(f3,sqrt);
                            1              1/2
                       {----------, (x - y)   }
                               1/2
                        (x - y)

are selected and replaced by 'g'.

However, I am not convinced that such designed behavior, i.e.

type(1/sqrt(x),sqrt);
                                 true

is fine.

It can also be done this way:

applyrule((x-y)^n::fraction=g^(2*n),f3);

                             a/g + b + g

It can also be done this way:

applyrule((x-y)^n::fraction=g^(2*n),f3);

                             a/g + b + g

May be not best, but at least I would be expected correct 'latex' output, instead of:

normal(1/((omega^Omega/a-1/2)[a,sqrt(2)][1/2]-(zeta+iota)[-y]
[-1,1]+(xi+Xi)[alpha[1/2]])):
latex(%);

- \left( -{\frac {{\omega}^{\Omega}}{a}}-1/2_{a,\sqrt {2};
{1/2}}+\zeta+\iota_{-y;{-1,1}}-\xi+\Xi_{{\alpha_{{1/2}}}} \right) ^{-1}

with missing brackets, etc.

For me, the key point is that the error messages are issued to be read by the user, and have to be understandable by any ordinary user. Whatever it tells about the user input, should be clearly identifiable in terms of what the user has typed.

So, when I say that an object is absent, it means absent in what the user has typed. Namely, if the user has typed <Fx,Fy>, and there is a problem with that, the error message should return in terms of <Fx,Fy>, not  Vector(2...) or whatever is the result of parsing, processing, etc. I do not believe that it involves any extraordinary technological achievement to reach such level of user friendliness. 

And I do not find clear that this issue is so generic, e.g. here:

dsolve(2,diff(y(x),x)=0,1,2,3);

Error, (in dsolve) expecting an ODE or a set or list of ODEs. 
Received 2

the error message is more clear on what is wrong and what is the expected syntax.

For me, the key point is that the error messages are issued to be read by the user, and have to be understandable by any ordinary user. Whatever it tells about the user input, should be clearly identifiable in terms of what the user has typed.

So, when I say that an object is absent, it means absent in what the user has typed. Namely, if the user has typed <Fx,Fy>, and there is a problem with that, the error message should return in terms of <Fx,Fy>, not  Vector(2...) or whatever is the result of parsing, processing, etc. I do not believe that it involves any extraordinary technological achievement to reach such level of user friendliness. 

And I do not find clear that this issue is so generic, e.g. here:

dsolve(2,diff(y(x),x)=0,1,2,3);

Error, (in dsolve) expecting an ODE or a set or list of ODEs. 
Received 2

the error message is more clear on what is wrong and what is the expected syntax.

But the main problem are the error messages that do not help much. E.g. introducing the same wrong argument "2" in the 'VectorField' call, as the OP did:

with(VectorCalculus):
Fx := 2*(X-u)/((X-u)^2 + Y^2)^(3/2):
Fy := 2*Y/((X-u)^2 + Y^2)^(3/2):
F := VectorField(2, <Fx,Fy>, cartesian[X,Y] );

you get this very long and confusing message that mentions an object 'Vector(2, ....' that is absent in the 'VectorField' call:

Error, invalid input: too many and/or wrong type of arguments 
passed to VectorCalculus:-VectorField; first unused argument 
is Vector(2, [...], datatype = anything, attributes = 
[coords = cartesian[X,Y]])

The "advantage" of using expressions instead of functions, is that the error message appears at the execution of the 'VectorField' statement and not later, where it makes even less sense.

But the main problem are the error messages that do not help much. E.g. introducing the same wrong argument "2" in the 'VectorField' call, as the OP did:

with(VectorCalculus):
Fx := 2*(X-u)/((X-u)^2 + Y^2)^(3/2):
Fy := 2*Y/((X-u)^2 + Y^2)^(3/2):
F := VectorField(2, <Fx,Fy>, cartesian[X,Y] );

you get this very long and confusing message that mentions an object 'Vector(2, ....' that is absent in the 'VectorField' call:

Error, invalid input: too many and/or wrong type of arguments 
passed to VectorCalculus:-VectorField; first unused argument 
is Vector(2, [...], datatype = anything, attributes = 
[coords = cartesian[X,Y]])

The "advantage" of using expressions instead of functions, is that the error message appears at the execution of the 'VectorField' statement and not later, where it makes even less sense.

As far as I understand it, in nested sums, the range of the variable in the outer sum is not taken as assumption by the inner one. So, this way it works:

sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m) assuming m::integer,m>=0;

                                  4
                            --------------
                                         m
                            (2 - m)! m! 2

sum(%,m=0..2);
                                 9/2

Similar problem occurs with nested integrals. And the new single call syntax solves this problem. From ?int > Description:

Note: The notation int(expression, [x = a..b, y = c..d])
is equivalent to int(int(expression, x = a..b), y = c..d)
except that the single call to int accounts for the range
of the outer variables (via assumptions) when computing
the integration with respect to the inner variables.

So, I think, something similar would be needed for sums.

As far as I understand it, in nested sums, the range of the variable in the outer sum is not taken as assumption by the inner one. So, this way it works:

sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m) assuming m::integer,m>=0;

                                  4
                            --------------
                                         m
                            (2 - m)! m! 2

sum(%,m=0..2);
                                 9/2

Similar problem occurs with nested integrals. And the new single call syntax solves this problem. From ?int > Description:

Note: The notation int(expression, [x = a..b, y = c..d])
is equivalent to int(int(expression, x = a..b), y = c..d)
except that the single call to int accounts for the range
of the outer variables (via assumptions) when computing
the integration with respect to the inner variables.

So, I think, something similar would be needed for sums.

In the usual convention, except for US mathematicians apparently, (r,theta,phi) is right handed. Indeed, I am not aware of a Physics book using the other convention.

But, even if different developers wanted to use different conventions, the person coordinating them should have indicated which one to use, or better, make available a system-wide convention of the user's choice.

In the usual convention, except for US mathematicians apparently, (r,theta,phi) is right handed. Indeed, I am not aware of a Physics book using the other convention.

But, even if different developers wanted to use different conventions, the person coordinating them should have indicated which one to use, or better, make available a system-wide convention of the user's choice.