Since the OP asked about numerical verification, here's a start on that.

It uses the fact that `evalf/D` calls the fdiff procedure, which does numeric differentiation.

I'm not going to get into specifying error tolerances and working precision.

Note the two different schemes for approximating the second derivative, one of which doesn't do as well.

restart;
DE := diff(y(x), x, x) = 1/y(x) - x*diff(y(x), x)/y(x)^2:
sol := dsolve({DE, y(0)=1, D(y)(0)=0}, numeric, output=listprocedure):
Y := eval(y(x), sol):
dY := eval(diff(y(x),x), sol):
#
# This evaluates the rhs of the DE using the dsolve/numeric
# approximation for both y(x) and diff(y(x),x) .
#
RHS := eval(eval(rhs(DE), diff(y(x),x)=dY(x)), y(x)=Y(x));
                             1     x dY(x)
                     RHS := ---- - -------
                            Y(x)        2 
                                    Y(x)  

#
# Under evalf/D this will numerically compute the
# first derivative of the dsolve/numeric approximation
# for diff(y(x),x), thus approximating the second
# derivative of y(x).
#
LHS1 := convert( eval(lhs(DE), diff(y(x),x)=dY(x)), D);
                        LHS1 := D(dY)(x)

#
# Under evalf/D this will numerically compute the
# second derivative of the dsolve/numeric approximation
# for y(x), thus approximating the second
# derivative of y(x). (This scheme does not do as well.)
#
LHS2 := convert( eval(lhs(DE), y(x)=Y(x)), D);
                     LHS2 := @@(D, 2)(Y)(x)

plot(LHS1-RHS, x=0..2, size=[500,200]);

plot(LHS2-RHS, x=0..2, size=[500,200]);

ode_evalf_D.mw

You can get smoother surfaces here by passing an increased value for the grid option.

Oloid_ac.mw

I also changed the color and the style, to try and show the smoother surfaces without the gridlines obscuring the improvement.

You almost always respond here with Replies, rather than Answers. That is not new behaviour.

A Reply cannot receive a thumb's-up or a vote, or best-Answer cup-icon. An Answer can. (I believe that this technically addresses your query.) This is just how the site's mechanisms currently work. That is not very new behaviour.

I usually/often change your Replies to Answers, when appropriate, which allows them the receive votes. I don't always do it.

I don't know why you invariably submit Replies rather than Answers. There are buttons for each, just below a Question's body.

There are many ways to go about this. It may depend upon whether you want to only display the results, how fancy you want to get it, or whether also to compute further with the values.

I'll repeat some operations here, to try and make some possibilities clearer.

restart;
T := t -> (t+459.47) * 5/9:

# a Vector of a sequence of values
V := <seq(t, t=100..250, 25.0)>;

# applying T, elementwise, to V
T~(V);

# two Vectors joined as a Matrix
M := < V | T~(V) >;

printf("\n%10.2f\n", M);

# with a header row
M := < < Unit(degF) | Unit(kelvin) >, < V | T~(V) > >:
M;

DocumentTools:-Tabulate(M, width=250, widthmode=pixels,
                        fillcolor=((M,i,j)->`if`(i=1,"LightBlue","Azure"))):

table_of_values.mw

For this example, would you accept an implicit (exact) solution, verified by implicit differentiation?

restart;

ee := diff(y(x),x,x) = 1/y(x) - x*diff(y(x),x)/y(x)^2;
impsol := dsolve(ee, implicit);

implicitdiff(eval(lhs(impsol),y(x)=y), y, x):
E1 := diff(y(x),x) = subs(y=y(x), %);
E2 := diff(y(x),x,x) = simplify( diff(rhs(E1), x) );

simplify( eval(eval((lhs-rhs)(ee),E2),E1) );

                   0

Another way to accomplish this is to construct them as names (entities).

This has an added benefit that they display directly in the Maple GUI without doublequotes when using regular print. As shown below, they also work with printf.

There are two choices for lowercase sigma. I have chosen the lowercase sigma σ, that is more often used in mathematics, rather than the lowercase sigma ς for word-final position.

restart;

Greek_uppers:=["Alpha","Beta","Gamma","Delta","Epsilon","Zeta","Eta", 
               "Theta","Iota","Kappa","Lambda","Mu","Nu","Xi","Omicron",
               "Pi","Rho","Sigma","Tau","Upsilon","Phi","Chi","Psi","Omega"]:
Greek_lowers:=map(StringTools:-LowerCase,Greek_uppers):
Greek:=table([seq(Greek_uppers[i]=nprintf(`&#%ld;`,912+i),i=1..17),
               seq(Greek_uppers[i]=nprintf(`&#%ld;`,912+i+1),i=18..24),
               seq(Greek_lowers[i]=nprintf(`&#%ld;`,944+i),i=1..17),
               seq(Greek_lowers[i]=nprintf(`&#%ld;`,944+i+1),i=18..24)]):

seq(printf(" %s  %s   %s\n", Greek[g], Greek[StringTools:-LowerCase(g)], g),g=Greek_uppers);
 Α  α   Alpha
 Β  β   Beta
 Γ  γ   Gamma
 Δ  δ   Delta
 Ε  ε   Epsilon
 Ζ  ζ   Zeta
 Η  η   Eta
 Θ  θ   Theta
 Ι  ι   Iota
 Κ  κ   Kappa
 Λ  λ   Lambda
 Μ  μ   Mu
 Ν  ν   Nu
 Ξ  ξ   Xi
 Ο  ο   Omicron
 Π  π   Pi
 Ρ  ρ   Rho
 Σ  σ   Sigma
 Τ  τ   Tau
 Υ  υ   Upsilon
 Φ  φ   Phi
 Χ  χ   Chi
 Ψ  ψ   Psi
 Ω  ω   Omega

note. I course, you can also easily convert the strings that Carl constructed into names, eg, convert(...,name) , etc.

[edit] Also, the methodology that Carl used, with the StringTools:-Char command, will also work in the plaintext console-driven Maple Command-Line Interface (CLI) and not just the Maple GUI.

For fun, see also this old Question.

You could look at the Help page for the unassign command.

It doesn't appear that Ag2O is one of the chemical names recognized by the ThermophysicalData package in current Maple.

Also, programmatically,

map(proc(s) `if`(StringTools:-Search("Ag",s)>0,s,NULL); end proc,
    ThermophysicalData:-Chemicals:-GetSpecies());

        ["Ag(g)", "Ag+(g)", "Ag-(g)", "Ag(cr)", "Ag(l)"]

The reference seems to be this:
McBride, Bonnie J.; Zehe, Michael J.; and Gordon, Sanford. NASA Glenn Coefficients
for Calculating Thermodynamic Properties of Individual Species; 2002

Why not try the factor command, to attempt to factor out a term of a common power?

expr := y^2+y^3*sin(x)+3*x*y^5;

                         2    3               5
                expr := y  + y  sin(x) + 3 x y 

aa := factor(expr);

                       2 /     3               \
                aa := y  \3 x y  + sin(x) y + 1/

For this example the factored form is not "smaller" by the metrics used by simplify. But you can avoid that with an option:

simplify(expr, size=false);

                    2 /     3               \
                   y  \3 x y  + sin(x) y + 1/

Fwiw, using these metrics,

H := ee->[`simplify/size/size`(ee),
          MmaTranslator:-Mma:-LeafCount(ee),length(ee)]:

H(expr), H(aa);

          [48, 16, 41], [48, 16, 45]

[edit] You can also use factor with frontend. That works for the example involving rational powers (radicals) you added in an edit to your Question (one of two ways which handle that example, which I showed in my Reply to that new information first presented under mmcdara's Answer).

You've stated a goal of factoring. So useful commands can include:

factor(...)
evala(Normal(...))
frontend(factor,...)
simplify(..., size=false)
simplify(...)
evala(Factor(...))

depending on your (as yet unstated) goal requirements, restrictions, and problem class.

Add the explicit option to your call to the solve command, if you want roots in terms of explicit radicals instead of implicit RootOf.

help_ac.mw

You could also read the Help page for topic solve,details.

You could use an overlay of lines and point-plots, and legends, to illustrate the close curves.

The final call to plots:-display uses them in a particular order, so that they are laid over each other in a particular order.

restart:
f1:=x->0.95*x:
f2:=x->0.99*x:
f3:=x->0.991*x:
# adjust these, to taste
N:=10: ptsize:=8: th:=1:
(a,b) := 0,2:
p1:=plot(f1(x),x=a..b,color=red,thickness=th,legend=f1(x)):
p1a:=plot(f1(x),x=a..b,color=red,
          style=point,symbol=solidcircle,symbolsize=ptsize,
          adaptive=false,numpoints=N+1):
p2:=plot(f2(x),x=a..b,color=blue,thickness=th,legend=f2(x)):
p2f:=plot(f2(x),x=a..b,color=blue,thickness=th+2):
p2a:=plot(f2(x),x=a+(b-a)/(N*2)..b-(b-a)/(N*2),color=blue,
          style=point,symbol=solidcircle,symbolsize=ptsize,
          adaptive=false,numpoints=N):
p3:=plot(f3(x),x=a..b,color=green,thickness=th,legend=f3(x)):
p3a:=plot(f3(x),x=a..b,color=green,
          style=point,symbol=solidcircle,symbolsize=ptsize,
          adaptive=false,numpoints=N+1):
plots:-display(p1,p2,p2f,p3,p3a,p2a,p1a);

plots_close.mw

Another way is to overlay with a duplicate having different linestyle.

restart:
f1:=x->0.95*x:
f2:=x->0.99*x:
f3:=x->0.991*x:
(a,b) := 0,2:
p1:=plot(f1(x),x=a..b,color=red,legend=f1(x)):
p2:=plot(f2(x),x=a..b,color=blue,legend=f2(x)):
p2a:=plot(f2(x),x=a..b,color=blue,linestyle=dash):
p3:=plot(f3(x),x=a..b,color=green,legend=f3(x)):
plots:-display(p1,p2,p3,p2a);

From the Help page for topic I,

It is not a protected name, because it is not implemented to evaluate as a name.

That distinguishes it from other initially known names and constants.

dismantle(I);

COMPLEX(2)
   INTPOS(2): 1

type(I, name);

             false

Complex(1);

               I

dismantle(Pi);

NAME(4): Pi #[protected]

Pi;                                                                                
               Pi

[edit] Also,

op(0,I), [op(I)];

           Complex, [1]

It is like that by design. From one point of view this is beneficial because it allows you to construct an exploration for which you can subsequently redefine variables or assigned names.

If you upload and attach your worksheet then we may be able to show you more than one way to work with the design, so that your example works more as you want.

You mentioned "variables", which could mean parameters (in the Explore sense) or additional variables with assigned values. An explicit example from you would make you meaning more clear. Explore parameters have to be unassigned global names -- but even for them it is often possible to programmatically work around some issues.

In one sense this is part of a broader Maple worksheet subject: execution of previous parts can be re-executed out-of-order, and if that is the intention then the burden is on the user to set up examples which guard against collision in the namespace. [edit. I see that Carl made this same point, while I was typing.]

I have not yet pinpointed the precise cause of the problem.

But here is something quick, in my Maple 2020.1.

restart;

(-1)^v*(alpha*GAMMA(k-v)/v!/GAMMA(k-2*v-1)/GAMMA(k-2*v))^(1/2)
*exp(-1/2*k*exp(-alpha*x))*(k*exp(-alpha*x))^(1/2*k-v-1/2)
*LaguerreL(v,k-2*v-1,k/exp(alpha*x))/binomial(k-v-1,v):

CodeTools:-Usage(
  seq((evalf[15](Int(unapply(simplify(eval(%, [k=30.5, v=j, alpha=2.5]))^2, x),
                     -1..infinity))), j=0..5) );

memory used=27.47MiB, alloc change=34.00MiB, cpu time=260.00ms, real time=261.00ms, gc time=24.22ms

     0.999999999999992, 0.999999999999994, 1.00000000000001,
     1.00000000000001, 1.00000000000001, 0.999999999999959

Here is a way to substitute names c[i] for the _Cn constants, which also forces the reordering so that specified names c[i] are first in the product subterms. It uses subs for the substitution, as opposed to alias.

This uses sort, and can forcibly correct the example even when the "uniquified" expression (stored by the kernel as the sole representation) has been inadvertantly reordered in a manner contrary to your goal.

sorting_fun.mw

Unfortunately inlining of uploaded worksheets is currently broken on Mapleprimes.

It also finds the _Cn names as they appear, alleviating need to hard code a fixed number of replacements up front. (Other Answers hard-coded 10 substitutions.)

If you come across an example which it cannot handle directly then the procedure could be adjusted accordingly.

Some of the other suggestions (in other Answers) are not always assured to produce the desired ordering of the terms, eg. in cases where the misordered expression have previously existed in the session. So the ability to force the ordering seems useful.