In Maple 2015 Classic GUI and the CLI, as well as in Standard for previous versions of Maple, the result is:

> eval(sqrt);
        module() local ModuleApply, Nested, Product, Primes;  end module

While in Maple 2015 Standard GUI, the result looks like:

eval(sqrt);
        module() ...  end module

So, yes, it can be considered as a regression in the Standard GUI.

OK, a toy version, as a demonstration of the idea of plotting a scalar field f(x,y,z) on a cubic array of points, with color after the value of the scalar field at the point:

f:=(x,y,z)->evalf(sin(x/Pi)*sin(y/Pi)*sin(z/Pi)):
coordseq:=seq(seq(seq([i, j, k], i = 1 .. 5), j = 1 .. 5), k = 1 .. 5):
colorseq:=seq(seq(seq(f(i,j,k), i = 1 .. 5), j = 1 .. 5), k = 1 .. 5):
PLOT3D(POINTS(coordseq), SYMBOL(BOX), AXESSTYLE(NORMAL),COLOR(HUE,colorseq));

This is a bug of the typesetting extended mode of the Standard GUI, not from series itself, check the result executing lprint(%). A workaround is setting it to standard, e.g. by interface(typesetting=standard).

Actually, this is an old regression bug observable already in Maple 13.02 (on Linux). Note, by the way, that the extended typesetting mode is well known for this kind of problems. Observe, for instance, the +- signs in the 3th and  7th powers in the output of series(exp(I*x),x,8), and read this thread.

It seems that you are looking for an asymptotic expansion about m=infinity, like:

> ex:=f(sqrt(m/(m+1))*(x+1/(2*sqrt(m))), sqrt(m/(m+1))*(y-1/(2*sqrt(m)))):
> MultiSeries:-series(ex,m=infinity,2);
                                                             1/2
      f(x, y) + (1/2 D[1](f)(x, y) - 1/2 D[2](f)(x, y)) (1/m)    + O(1/m)

There are some problems with that step-by-step calculation, in regards to validity of those results. First, integration by parts:

> with(IntegrationTools):
> J:=Int(ln(1+sqrt((x+1)/x)),x):
> J1:=Parts(J,ln(1+sqrt((x+1)/x)));
                                                 /      x + 1\
                                      /        x |1/x - -----|
                                     |           |        2  |
                      /x + 1\1/2     |           \       x   /
       J1 := x ln(1 + |-----|   ) -  |  ----------------------------- dx
                      \  x  /        |    /x + 1\1/2 /    /x + 1\1/2\
                                     |  2 |-----|    |1 + |-----|   |
                                     |    \  x  /    \    \  x  /   /
                                    /

Note the differences. In general sqrt((x+1)/x) <> sqrt(x+1)/sqrt(x), etc. Now, the result you show requires using simplify(...,symbolic) on the integral like:

> evalindets(J1,specfunc(Int),u->simplify(u,symbolic));
                                    /                1/2
                /x + 1\1/2         |                x
       x ln(1 + |-----|   ) + 1/2  |  -------------------------------- dx
                \  x  /            |         1/2             1/2  1/2
                                  /   (x + 1)    (x + (x + 1)    x   )

But simplify(...,symbolic) is producing a result disregarding branch cuts. Meaning a result that is generically wrong. Certainly, it migth be right somewhere in the complex plane. But even then, you would have to discover where. So, that step-by-step tool is not the safe way to go for this kind of integrals.

On the other hand, it works for a^2<>1, not only a=2:

> Int(ln(a+sqrt((x+1)/x)),x):
> F:=value(%);
                                /
            /x + 1\1/2          |
F := ln(a + |-----|   ) x - 1/4 |
            \  x  /             |
                                \
                                                    /    2    \1/2
      4               1/2                       1/2 |   a     |
    -a  ln(((x + 1) x)    + x + 1/2) ((x + 1) x)    |---------|
                                                    |  2     2|
                                                    \(a  - 1) /
...

Meaning that this "generic" result is badly behaved at a=1 (it has a branch point there in the complex plane a). This is not the way to go. The case a=1 has to be dealt as a special case. And yes, those steps can be made right:

> J2:=simplify(J1);
memory used=1.0MB, alloc=38.3MB, time=0.05
                                        /
                    /x + 1\1/2         |                1
     J2 := x ln(1 + |-----|   ) + 1/2  |  ----------------------------- dx
                    \  x  /            |    /x + 1\1/2 /    /x + 1\1/2\
                                      /   x |-----|    |1 + |-----|   |
                                            \  x  /    \    \  x  /   /
> student[changevar](sqrt((x+1)/x)=u,J2,u);
                                      /
                                     |           2
                  x ln(1 + u) + 1/2  |  - ---------------- du
                                     |      2
                                    /     (u  - 1) (1 + u)
> F1:=value(%);
                                                 1
         F1 := x ln(1 + u) - 1/4 ln(u - 1) - --------- + 1/4 ln(1 + u)
                                             2 (1 + u)
> F2:=eval(F1,u=sqrt((x+1)/x));
               /x + 1\1/2           /x + 1\1/2                1
F2 := x ln(1 + |-----|   ) - 1/4 ln(|-----|    - 1) - ------------------
               \  x  /              \  x  /             /    /x + 1\1/2\
                                                      2 |1 + |-----|   |
                                                        \    \  x  /   /
                  /x + 1\1/2
     + 1/4 ln(1 + |-----|   )
                  \  x  /

As a note for improvements in the indefinite integration sector, it happens that similar cases fail because the computation is dispatched to a procedure for handling integrands with logarithm, it fails and never returns to try integration by parts. So, in principle yes, that part would be easy to fix...

Some kind of alternative to the stop button is calling with timelimit. See, e.g. the threads:

Stopping Numeric Integration after a time limit

how to set CPU limit on buildin operation such as int or dsolve?

Certainly, simple expressions like 1+1 are affected by automatic simplification, which operates in Maple before any evaluation takes place. Hence '1+1' yields 2 in Maple, probably an important difference in design between Maple and Mathematica (see e.g. the help page for Defer). So, in Maple, a way out is using the package InertForm, like:

> with(InertForm):
> (Display@Parse)("1+1");
                                           1 + 1

For Maple 17, I have submitted a SCR, very similar to yours, just about an even more trivial operation:

Grid[Seq]( i, i=1..10^7 ) : 

Obtaining "Error, (in Grid:-Launch) deadlock detected", while the behavior for a smaller upper limit like 10^6 was either deadlock or unending computation. This particular issue was recognized as a bug and fixed for Maple 18. So, I think that you should also submit a SCR.

This numeric exception occurs when trying abs(y-1)=395718860533:

> 625^395718860533;
Error, numeric exception: overflow

in a substitution:

> stoperror("numeric exception"):
> testeq(eqn1);
Error, numeric exception: overflow
testeq:
  67         e1 := subs(('abs')(qq[2]) = qq[3],('abs')(-qq[2]) = qq[3],expr);
DBG> expr
5^(2*abs(y-1)+2)-1/15625*625^abs(y-1)
testeq:
  67         e1 := subs(('abs')(qq[2]) = qq[3],('abs')(-qq[2]) = qq[3],expr);
DBG> qq[2]
y-1
testeq:
  67         e1 := subs(('abs')(qq[2]) = qq[3],('abs')(-qq[2]) = qq[3],expr);
DBG> qq[3]
395718860533
...

May be that the case of exponentials is not properly addressed...

You may try exporting the plots using the Command line interface (CLI).

It looks like a regression bug in the renderer of the Standard GUI (see e.g. here). It works (produces a plot) in Classic GUI and it works in Maple 15 Standard GUI and earlier. Moreover, the data structure produced in Maple 18 Standard GUI, say, renders fine in Maple 15 Standard GUI.

Note, on the other hand, that the plot produced by:

> with(plots):
> implicitplot3d(z=sqrt(4-x^2-y^2),x=-2..2,y=-2..2,z=-2..2);

is only the z>0 half of the sphere.

PD I have observed that the maplet renderer is also affected in the same versions (Maple 16 on). Hence, may be that the actual problem is located in some preprocessing stage running in Java code. Moreover, it looks like this problem is related to handling the sqrt (or (...)^(1/2)), when its argument is negative, producing undefined (for complex values) in the ISOSURFACE plot object. And also, this object is still implemented in the old nested list style instead of Array, as other PLOT3D objects in recent versions of Maple.

Apparently, Not(And(x>4,y>4)) works better as a representation of the complementary set:

> cset:=Not(And(x>4,y>4));
                        cset := Not(And(4 < x, 4 < y))
> solve(cset,{x,y});
                        {y = y, x <= 4}, {x = x, y <= 4}

This result is correct, though not entirely satisfactory because of overlap (the subset {x<=4,y<=4} occurs twice).

Have you tried removing cookies?

For reading the code used by inttrans[laplace], you could issue showstat(`inttrans/laplace`) and then continue with the procedures under it: showstat(`inttrans/laplace/main`) and so on (the library browser LibraryTools:-Browse() may help here, though it is very buggy). On the other hand, an extension mechanism is provided for adding entries to the lookup table for the integral transforms, see ?inttrans,addtable .

This problem seems rather unrelated from RealDomain and assumptions, simply compare:

> solve({(1/(a-1)-1/(a+1))*(2*a^2-2)/a = 4/surd(2, 2), a <> 1, a <> -1});
                               1/2
                         {a = 2   }, {a = 1}, {a = -1}
> solve({x^2 = 1, x <> 1});
                                    {x = -1}

Indeed, this is a regression bug. In Maple 9.52:

> solve({(1/(a-1)-1/(a+1))*(2*a^2-2)/a = 4/surd(2, 2), a <> 1, a <> -1});
                                         1/2
                                   {a = 2   }

Basically, the problem seems to occur at checking the inequalities, when substituting the solutions into the inequalities. In the second example it means substituting the solution x=1 into the inequality x-1<>0, producing the contradiction 0<>0 which excludes this solution, see here how it works:

> trace(SolveTools:-Substitute):
> solve({x^2 = 1, x <> 1});
{--> enter SolveTools:-Substitute, args = x = 1, x-1 <> 0
                                thesubs := x = 1
                               expr := x - 1 <> 0
<-- exit SolveTools:-Substitute (now in PolynomialSimple) = 0 <> 0}
{--> enter SolveTools:-Substitute, args = x = -1, x-1 <> 0
                               thesubs := x = -1
                               expr := x - 1 <> 0
<-- exit SolveTools:-Substitute (now in PolynomialSimple) = -2 <> 0}
                                    {x = -1}

While in the first example a problem occurs:

> solve({(1/(a-1)-1/(a+1))*(2*a^2-2)/a = 4/surd(2, 2), a <> 1, a <> -1});
{--> enter SolveTools:-Substitute, args = t = RootOf(_Z^2-2,index = 1), {a-1 <>
0, a+1 <> 0}
                                           2
                   thesubs := t = RootOf(_Z  - 2, index = 1)
                        expr := {a - 1 <> 0, a + 1 <> 0}
<-- exit SolveTools:-Substitute (now in Polynomial) = {a-1 <> 0, a+1 <> 0}}
{--> enter SolveTools:-Substitute, args = t = -1, {a-1 <> 0, a+1 <> 0}
                               thesubs := t = -1
                        expr := {a - 1 <> 0, a + 1 <> 0}
<-- exit SolveTools:-Substitute (now in Polynomial) = {a-1 <> 0, a+1 <> 0}}
{--> enter SolveTools:-Substitute, args = t = 1, {a-1 <> 0, a+1 <> 0}
                                thesubs := t = 1
                        expr := {a - 1 <> 0, a + 1 <> 0}
<-- exit SolveTools:-Substitute (now in Polynomial) = {a-1 <> 0, a+1 <> 0}}
{--> enter SolveTools:-Substitute, args = [RootOf(_Z^2-2,index = 1) = 2^(1/2)]
, [{a = RootOf(_Z^2-2,index = 1)}, {a = -1}, {a = 1}]
                                      2                    1/2
                 thesubs := [RootOf(_Z  - 2, index = 1) = 2   ]
                                2
         expr := [{a = RootOf(_Z  - 2, index = 1)}, {a = -1}, {a = 1}]
<-- exit SolveTools:-Substitute (now in Radicals) = [{a = 2^(1/2)}, {a = -1}, {
a = 1}]}
                               1/2
                         {a = 2   }, {a = -1}, {a = 1}

Namely,  the condition is expressed in one variable, like t = 1, while the inequations are expressed in a different variable {a-1 <> 0, a+1 <> 0}. So, apparently, no substitution is made and the contradictions are not reached...