Couldn't any question with title beginning with http be removed automatically? There has been quite a few containing nothing but spam.

In working on an answer to a recent question on MaplePrimes:
http://mapleprimes.com/questions/210948-Can-We-Trust-Maple

I noticed that in solving a "simple" system of two equations in two unknowns, potentially undesirable expansion occurs.
The two equations were only simple in the sense that the solving was very trivial, since the two unknowns occurred (almost) already isolated on the left:
eq1:=diff(x(t),t)=rhs1;
eq2:=1.2345*diff(v(t),t)=rhs2; #rhs2 is very complicated in the link given.
So in isolating I tried:
solve({eq1,eq2},{diff(x(t),t),diff(v(t),t)});
The resulting ode system took considerably longer to solve numerically than an unexpanded version.
It is trivial (of course) to do the solving without solve in this case.

Here is an extremely simple example, where the unknowns are already isolated, so that the equations themselves are actually the solution.

restart;
eq1:=a=b*(c+d);
solve(eq1,a); #No expansion
eq2:=e=b*(c+d)+f*(8+k);
solve({eq1,eq2},{a,e}); #Expanded:
                   {a = b*c+b*d, e = b*c+b*d+f*k+8*f}

Can expansion be avoided?

The question in the title has been raised before over the years, but has maybe not received enough attention.
Reraising the question was motivated by a comment by Kitonum to a recent post on improved integration results in Maple 2016:
http://mapleprimes.com/maplesoftblog/202910-New-And-Improved-Integration-Results

Consider the following session.
restart;
assume(n=0);
n^2; #Returns n^2
eval(%);#Returns n^2
sin(n*Pi); # Returns 0
sin(n); # Returns sin(n)
eval(%); # Returns sin(n)
ln(n); #Returns ln(n)
ln(n*exp(1)); # Returns ln(n*exp(1))
expand(%); # Error, (in ln) numeric exception: division by zero
ln((n+1)*exp(1)); Returns ln((n+1)*exp(1))
expand(%); # Returns ln(n+1)+1
sqrt(n^2); # Returns 0
sqrt(n); # Returns n^(1/2)
eval(%,n=n^2); # Returns (n^2)^(1/2)
simplify(%); #Returns 0: simplify doesn't help in the examples above.
##################
We see that assume n=0 certainly doesn't imply that expressions always will be evaluated at n=0, but sometimes it appears that it does.
So what is the intended behavior when assuming equality?
##
Several years ago (Maple 14 or earlier) I overloaded assuming so that equality assumptions were handled by eval.
There was a discussion at the time in MaplePrimes about this. Shall try to find the link.

I recently got myself a 64 bit computer and have noticed that I cannot use the option compile=true in dsolve/numeric. Take the following simple example:

dsolve({diff(x(t),t)=x(t),x(0)=1},numeric,compile=true);
Error, (in dsolve/numeric/SC/preproc) unable to compile (rc=1), please try again, and if that fails verify your Windows compiler installation

I'm using Windows 10, but had the same problem with Windows 8.1 on the same machine.
The Compiler:-Compile examples in the help page all work.

What do I have to do to make the option compile=true work in dsolve/numeric?

You may safely assume that I don't know any technicalities about these things.

Which Maple versions will run on Windows 10? Windows 10 is offered free to users of Windows 7 and 8.1. Several (including old) Maple versions run on Windows 7.