@tomleslie: Thanks for your feedback and for your proposal on how to easily fix the issue.

I am surprised that there is no way to control the naming of the integration constants. Likewise I am surprised that PDEtools:-Solve have not been programmed to make sure that the numbering of integration constants, etc., will not conflict with any indeterminates already present in the system of equations. I think that that should have been relatively easy to do. If it had been done, then 1.) one would not walk into the trap I did - it took me some while to actually locate my 'mistake'; and 2.) one would not have to resort to this renaming stuff.

What, by the way, are 'variable separation constants'?

@Ramakrishnan: I hope someone else can help you by providing you with some ideas/pointers on the subject.

@Ramakrishnan: I think I have misunderstood/misread your question: Focusing on the passage "How do i insert another module or procedure inside the above module?", I thought that you wanted to know how to have a module inside another module, providing the above example/template for that.

But now it appears to me that the subject is on embedded components. On that subject I have, unfortunately, no knowledge. The only thing I have been able to do is look for "plot0" (that you mention above) in the help pages, locating the help page ?DocumentTools:-Plot. Is that of any help to you?

@tomleslie: Thanks for your feedback. I am running the exact same Windows and Maple versions as you do. But the desktop icon still moves when the worksheet is resaved. However, having just checked again, this is all of a sudden the only odd thing that happens. Surprisingly, Alt-F4 does now close the program as it should. Mysterious!

@ecterrab: I believe I have never seen mixed type metrics used in the text books I have read/consulted over the years, for instance, the classic 'Gravitation', by Misner, Thorne, and Wheeler; or 'Tensors, Differential Forms, and Variational Principles', by Lovelock and Rund (both as previously mentioned in my comment to Adam Ledger). Nor do I believe it is present in 'The Classical Theory of Fields', by Landau and Lifshitz, having just loosely browsed through the relevant chapters.

Sorry to say, but I still think that having mixed type metrics and/or non-mixed type Kronecker deltas is bad, or at least unfortunate, notation. But perhaps it boils down to personal taste.

@ecterrab: Thanks for your comments. As you correctly suspect, I had not checked expressions like your (4) and (8), i.e., the actual equality of the metric and the Kronecker delta of corresponding tensor types. Although these equalities are of course reassuring, I still find the notation somewhat unfortunate, for Kronecker deltas of type (0,2) or (2,0) are not even tensors (as also explained in the link you provide); this was the my prime motivation for raising the issue in the first place.

I think I would have preferred a design in which Kronecker deltas of type (0,2) or (2,0) were deemed illegal in the realm of tensor calculus, and likewise for metrics of mixed tensor type. Or at least that the former were printed as metrics, and the latter were printed as Kronecker deltas. I say this because I have myself been a victim of the potential conceptual pitfalls associated with believing that such 'illegal' Kronecker deltas are tensors.

@Adam Ledger: The first chapters of the monograph 'Tensors, Differential Forms, and Variational Principles', by David Lovelock and Hanno Rund is a good text book, I think, because it spells out all the calculations in glorious detail. The only drawback is a slightly unconventional choice of the order of the indices of the socalled connection coefficients compared to other text books like, say, 'Gravitation', by Misner, Thorne, and Wheeler.

According to the help page on Eigenvectors, the generalized eigenvector problem consists in solving the equation A*x = lambda*C*x (using a somewhat sloppy notation). Your eigenvalue problem is not of that form; for it to actually be of that form, it seems to me that your lambda^2 should be replaced by -lambda (minus sign, and no power), taking, as you do, A = K and C = M. Whether such a substitution is sensible from a physical point of view, I have no idea.

@tomleslie & acer: Thanks for these further elaborations. Taking a look at the help page of list, it is clearly stated that, indeed, modifying a list creates a whole new list, a list being thus an immutable data structure. I guess, I have never really payed that much attention to these matters, having the bad habit of often just skimming help pages. I think I will have to read chapter 4 of the Programming Guide on Basic Data Structures, being referred to in that note.

@acer: Thanks for these more technical details. I am afraid, though, that they could exceed my abilities; that I will never be able to really absorb these matters into my programming. Being able to fully grasp these matters is perhaps what distinguishes the Maple masters from the mere mortals :-).

@acer: Having declared y local in the procedure, you actually mean f(y) <> y, not f(__y) <> __y, right?

@vv: Thanks for your input. As mentioned in my reply to Kitonum, I am still, though, trying to wrap my head around this concept of last name evaluation. I cannot say that it has really sunk in yet.

@tomleslie: Thanks for that suggestion. I guess it is effectively the same as using select, isn't it?

PS: See my PS to acer.

@Kitonum: Thanks for that idea. I am still trying to wrap my head around this last name evaluation business: I cannot really say I understand why your code works, while my original code did not. I will have to read the help page on last_name_eval a couple of times more and do some experimenting, I guess, before it hopefully sinks in.

@acer: Thanks for that info concerning "last name evaluation". Quite clearly I was not aware of that concept, at least not sufficiently so. With eval(f) instead of f,  i.e., with the previous code replaced by

nonIdMaps := []:
for f in [x -> x,x -> 2*x,x -> 3*x] do
   eval(f),f(y);
   if f(y) <> y then nonIdMaps := [nonIdMaps[],eval(f)] end if
end do;
nonIdMaps,map(f -> f(y),nonIdMaps);

it does indeed work. As this study case is a 'stand alone', I have not considered whether y could be accidentally assigned something; but of course, you have point.

PS: I know it is bad programming style to augment a list, but I guess I took a relaxed attitude towards it here, the code just being a study case.