why 'showstat' does not evaluate this table by default.

I was not aware that 'showstat' is not reliable in this sense ( printing different things the same way). This seems not to be documented.

I have tried your hints:

d:=[disassemble(addressof(RealDomain:-limit))];
	d := [8, 50221232, 51251268, 1768778092, 116]

but then 'pointto' gives error for d[1], d[4] and d[5]. And for d[2] I get the same printing "artifact". So, I do not see how to get the information this way.

On the other hand, with 'ToInert' I get:

ToInert([op(RealDomain:-limit)]);

...
_Inert_NAME("clean"), _Inert_LOCALNAME("clean",51227244,
_Inert_ATTRIBUTE(_Inert_ASSIGNEDLOCALNAME(":-5538","NAME",51243160,
...

Apparently, this is what you mean.

I meant RealDomain:-clean. Sounds that RealDomain:-limit could call another command 'clean' that could be around.

But if this were a printing artifact, how to know?

on the case, in particular on f(x). When the solutions of the nonlinear ODE are analytic  functions of b at b=0, a power expansion in b may give an approximation to these solutions. Otherwise, when not analytic at b=0, a singular perturbation problem occurs. See the linked article for some bibliography.

The point alone here:

with(plots): 
b := pointplot([0, 0], 
    symbolsize = 15, symbol = circle, color = blue): 
c := pointplot([0, 0], 
    symbolsize = 10, symbol = solidcircle, color = white): 
display( b, c);

is displayed with its center below the origin in the Standard GUI, while centered in the Classic GUI.

I like it as I plot in a window anyway. Another disadvantage, though, is that export does not seem to work for, say, plots:-polarplot(1). I get an error box:

Dispatch
unknown element _AXISCOORDINATES

My guess is that 'DifferentialGeometry' was not designed nor tested to work with spaces of more than a handful dimensions. I am not seeing examples with dim>5.

May be that for dim 20 or 100 some workarounds could be made by transforming to 'Array', kind of:

convert(F,DGtensor):
convert(%,DGArray);
                     [ 1..20 x 1..20 2-D Array ]
                     [ Data Type: anything     ]
                     [ Storage: rectangular    ]
                     [ Order: Fortran_order    ]

This article in Wikipedia lists several other applications, besides differential forms.  Indeed this is the stuff used by people working in  Supersymmetry (an approach to the subject of the elementary particles).

Tensors are of utmost importance in Physics. Many important magnitudes are tensors.

It is not so simple. As ?DifferentialGeometry  states, this package is based on the contributed package "Vessiot". In fact it is its 3-f cousin :)

The DiffferentialGeometry package is based upon  the Vessiot package 

Mathematics has many interlinked structures. But every package has a limited scope. Ie. I do not find realistic that any single package, like 'DifferentialGeometry',  provides support to all the possible  algebraic  extensions,  like the Grassman algebra here, even though it arises "naturally".

My (utopic) view is that a "unix" approach is needed, meaning that each tool has to do a single thing and do it well. And the strength of the system arises from the interoperation of the different tools. This means that a common infrastructure for intercomunication is needed ( kind of pipes). And a specification on how each package should behave for this intercomunication can work. So, in this view, though Maple has no Grassman algebra package yet,  in prevision for  when it becomes available, the packages that deal with an an exterior product (like the wedge product of 'DifferentialGeometry') should be ready for this comunication when that Grassman package is "pluged in".

So, my main concern is about the isolation of the different packages in their design and workings. Eg 'Differentialgeometry' provides representations for vectors, tensors, etc. And there are many other implementations of vectors and tensors elsewhere in the system. But very exceptionally they can pass such objects from one package to the other.

Then, the user becomes limited when trying to combine the tools provided by these packages. Ie the system as a whole wastes much of its development investment because of this lack of synergy.

Texmacs, despite its name, uses its own formater, not TeX. But it can export to LaTeX and other formats. It has buttons for the usual constructs (fractions, roots, etc). And most interestingly, it can work as a frontend to several mathematical programs via plugins: Maple, Maxima, Axiom, Mupad, Sage, R, etc. This is simpler in Linux than in Windows, though.

Texmacs, despite its name, uses its own formater, not TeX. But it can export to LaTeX and other formats. It has buttons for the usual constructs (fractions, roots, etc). And most interestingly, it can work as a frontend to several mathematical programs via plugins: Maple, Maxima, Axiom, Mupad, Sage, R, etc. This is simpler in Linux than in Windows, though.

I think that there were better candidates than me, though.

They are not defined. I have never used myself this algebra, but could it be that the Clifford package:
 
http://clifford.physik.uni.konstanz.de/~fauser
http://math.tntech.edu/rafal

is more oriented towards these structures?

I do not think that the package 'DifferentialGeometry' was designed to deal with Grassman algebra. I would say it is more oriented towards  Lie algebras (?DifferentialGeometry,LieAlgebras).

To make it work with '+' there should be an 'DifferentialGeometry' export for it. It would be less typing...

Differential geometry, Grassman algebra, are subjects of Mathematics that are of use in some fields of Physics. What may be different is the focus, being tools for physicists.

are the commands to add objects and multiply by scalars (?DifferentialGeometry[algebraic operations]).

with(DifferentialGeometry):
DGsetup([x,y],M):
a:=dx &wedge dy:
b:=a &plus 0;  

Error, (in DifferentialGeometry:-&plus) expected a "form", 
"biform", "vector" or "tensor", received: {0}

I think that using the top level '+' instead may be dangerous as it does not check or construct a DG data structure like:

op(0..,a);
                    _DG, [["form", M, 2], [[[1, 2], 1]]]

 Otherwise, with the top level product it does not work. E.g. to get component equations:

c:=f(x) &mult a=(alpha*x)  &mult a;
map(op@GetComponents,c, [dx &wedge dy]);

                               f(x) = alpha x

c1:=f(x) * a=alpha*x  * a;
map(op@GetComponents,c1, [dx &wedge dy]);

Error, (in evalapply) invalid input:
...