It's a bug about 0^x, not about odetest.

restart;
simplify(0^x) assuming x>0;
                 0^x
normal(0^x) assuming x>0;
                 0^x
eval(0^x) assuming x>0;
                 0^x
expand(0^x) assuming x>0;
                 0^x
0.0^x assuming x>0;
                 0.^x
#########################
is(0^x = 0) assuming x>0;
                 true
limit(0^x, x=x) assuming x>0;
                 0
eval(z^x, z=0) assuming x>0;
                 0
simplify(sin(0)^x) assuming x>0;
                 0
is(0.0^x = 0) assuming x>0;
                 true
#########################
eval(z^x, z=0) assuming x<0;   # ?
                 0

The bug seems to be rather old.
Also strange, in Maple 2018,  0^x  automatically simplifies to 0 (without any assumption).
I suspect that 0^x = 0 was removed from automatic simplification but the evaluation/simplification was not modified.
 

restart
dsolve( diff(y(x),x)=0, ['quadrature'])

Error, (in dsolve) numeric exception: division by zero

You asked a similar question recently.
In your examples dsolve simply does not eliminate a solution even when obtainable from another.
Anyway, note that actually:

•  (x + y(x))*(1+diff(y(x),x)) = 0 has one solution: y(x) = -x + c.
•  (x + y(x))*(a+diff(y(x),x)) = 0 has two solutions  (shown).
• (x + y(x))^2 *(1+diff(y(x), x))=0 has also one solution: y(x) = -x + c. 

If you express the ode in a standard form (as I told you in a comment a few days ago for a similar question),  ODESteps works.

restart;
ode1:=diff(y(x), x) = abs(x - 2)^(2/3);
ic:=y(2)=1;
Student:-ODEs:-ODESteps([ode1,ic]);

Note that the final result is actually 
y(x) = 1+3/5*abs(x-2)^(5/3)*signum(x-2);

Edit.
Maybe better (valid in complex too):
 

ode1:=diff(y(x), x) = ((x - 2)^2)^(1/3);

then:  

Your mysol is not in the form expected by odetest for an implicit solution: F(y(x), x) = 0; in this form everything is OK.

Of course, odetest could have converted mysol, but it does not; maybe it should.

This is an exact duplicate of your
 why is Maple not able to find solution to this first order ode? Only after adding implicit it can solve it - MaplePrimes

It was answered!

1. There should only be two (solutions).

Actually there is only one: y(x) = c1 * x + c2.

2. Where did the third solution come from? 

E.g. from y' y'' = 0 <==>  (y' ^ 2)' = 0 <==> y'^2 = c1^2 <==> y' = +- c1 <==> y = c1*x + c2 or  y = -c1*x + c2.

isolve recognizes several known equations such as Pytagorean triples, Pell's equation etc and uses the corresponding theorems or algorithms.

It is better and easier to use first symbolic parameters.

dsolve({diff(f(x),x) = a*f(x)^(2/3)+b*f(x), f(1)=c})

V := int(int(int(1, x = -x1 .. x1), y = -r .. r), z = 0 .. h) assuming positive;

restart;
Order:=20;
ode:=t*diff(u(t),t,t)+8*diff(u(t),t)+18*a*t*u(t)=-4*a*t*u(t)*ln(u(t));
ic1:=u(0)=1;   ic2:=D(u)(0)=0;
sol := dsolve([ode, ic1, ic2], u(t), series);
rec := gfun:-seriestorec(subs(sol, u(t)), A(n));
ode1 := gfun:-rectodiffeq(rec[1], A(n), u(t));

dsolve(ode1);
odetest(%, [ode, ic1, ic2]) assuming real;

                            
                       u(t) = exp(-a*t^2)
                           [0, 0, 0]

You may use
map(`*`, ineq, c);
It results a<b even when c is negative.
To avoid potential errors, you may use:
map(`*`, ineq, abs(c));  #  assuming c>0;

The "shortcut" < ... > obviously has very special evaluation (and parsing) rules, otherwise ";" would not work.

There are many Maple commands that do not accept directly sequence parameters. For example:

S := k, k=1..3;
#                       S := k, k = 1 .. 3

sum(S);
#                               6

add(S);
# Error, (in simpl/relopsum) invalid terms in product: 1 .. 3

add(S[1], S[2]);
#                              6

When you dsolve without IC, the branch of LambertW is not known and the generic branch "0" is used (instead "-1").

The correct approach is to use the option implicit for dsolve without IC. Then change accordingly eq. It will be OK.

A double (or multi) limit is in general more difficult than an iterated limit. But in your case the function (given by expr) is very simple, so both limits are easy to compute. And are indeed, if kernelopts('assertlevel'=2) is removed. However probably a  debugging assertion in limit/multi... produces the error.