@acer: Your suggestion, moving the uneval quotes to bracket only the unapply command itself, rather than the whole unapply expression, seems to do the trick in the context I need it. Thanks. The cost of calling 'unapply' is no issue for me.

@Preben Alsholm: Although the unevaluation quotes certainly do work for the test example given, there is still a problem with it, though, at least in the way I want to use it: I am building a sequence of such procedures, each procedure determined by some 'external' quantity. I think the following test example brings forth the issue:

F := [seq(unapply( unapply(u*theta*x,x) ,theta),u in [v1,v2])];
G := [seq(unapply('unapply(u*theta*x,x)',theta),u in [v1,v2])];
F(phi)(x);
G(phi)(x);

Here, two procedures are sought constructed, one for u = v1, and one for u = v2. Unfortunately, the unevaluation quotes in G 'block' u from being evaluated to either v1 or v2.

@vv: I have decided to implement your non-recursive function. Doing so, the following problem arises, though: If the Physics package has been loaded, then the while loop condition op(0,u) = diff fails because the right-hand side diff is actually Physics:-diff, while the left-hand side is diff. That, however, may be remedied by the following tiny correction op(0,u) = :-diff.

@Preben Alsholm: That does indeed explain it. Thanks. So converting higher order derivatives from diff to Diff is of no use, at least in that context.

@Preben Alsholm: Using D is also an interesting suggestion. Thanks for that idea. In fact, I toyed a little around with it myself before posting my question.

There is, however, something less than optimal about it, which was the reason why I ended up dismissing it: The coordinates being differentiated with respect to are identified by integers, rather than names. Although the names can, of course, be obtained by looking up the corresponding entries in the sequence of variables, it is somewhat annoying. But perhaps I am being unreasonable!?

Concerning the PDETools code your give: The problem with this is that one has to know which coordinates to search for.

In any case, I am surprised to learn that there seems to be no built-in functions in Maple for directly obtaining the requested quantities.

@vv: The inert form of diff, that is, Diff, is indeed interesting. Thanks for that idea. In conjunction with convert(), it would indeed provide a solution. But there seems to be a problem with convert(). Consider the following piece of code:

expr := Diff(f(x,y),x,y,y);
op(expr);
expr := convert(expr,diff);
op(expr);
expr := convert(expr,Diff);
op(expr);

It converts back and forth between the inert and non-inert forms of diff. But it seems that the last conversion fails, in that op(expr) returns a result corresponding to expr being in non-inert form, even though expr is rendered on screen with gray partial derivatives (corresponding to inert derivatives, according to the help page).

Thanks for your non-recursive function which is much better than my recursive function.

@acer: Even nicer! To me, that is the best solution so far. In fact, having just read the help page on the depends modifier, following the link you provide, it seems to be the way to do it. Just a little tweak, though:

det := (x::depends('Matrix'(dim$2))) -> Determinant(x);

@Preben Alsholm: I like your idea very much because of its inline type checking. I would like to tweak it as follows, though:

det := (x::satisfies(x -> type(x,'Matrix'(dim$2)))) -> LinearAlgebra:-Determinant(x)

Thanks to you all - acer, Carl, VV, Christian - for all your suggestions and replies, even though some of it is a bit over my head (which, of course, is not meant reproachfully).

However, I am still surprised to learn that in spite of all the various options Maple offers for the handling of parameters of procedures - required ones, optional ones, expected ones, etc. - there is, it seems, no way to evaluate a parameter of type name, if I understand it correctly. Why should that not be possible? Why not have available some command/declaration to force such an evaluation if desired?

By the way, a possible 'solution' is, of course, just to make a manual type check (but it bothers me to have to do that):

createModule2 := proc(A::Matrix(square))
   local dim;
   dim := RowDimension(A);
   module()
      export det;
      det := proc(x)
         if not type(x,'Matrix'(dim,dim)) then error "Wrong dimensions" end if;
         Determinant(x);
      end proc:
   end module
end proc:

Or perhaps the following way, using TypeTools (still not quite satisfactory, though):

with(LinearAlgebra):
with(TypeTools):
createModule2 := proc(A::Matrix(square))
   AddType(properSquareMatrix,(x) -> type(x,'Matrix'(RowDimension(A)$2))):
   module()
      export det;
      det := (x::properSquareMatrix) -> Determinant(x);
   end module
end proc:

@acer: A bug report concerning what? That they do not both fail, or do not both work?

@Christian Wolinski: Thanks for your solution createModule3, which does indeed seem to work. I must admit, though, that I do not understand the syntax of the determinantal procedure.

I like your solution, using the simple functions subs and eval.

@acer: Thanks for your answer. I am happy to note that the problem is nontrivial, apparently, as I feared that it was just me having misunderstood something fundamental.

Your write "I'm a tiny little surprised that either work." Do you by this mean that the way I write the code is not something one is supposed to do at all? The latter would surprise me, as I cannot see why some procedure inside some module could not have some of its parameters type-controlled by some parameter(s) used for constructing the module in the first place, just as outlined by my test case above.

My module is not that complicated, so I guess your unapply-suggestion - which is to me the most, or perhaps only, comprehensible workaround - will prove sufficient.

@Carl Love: Thanks for your hints. I did not know that the order af elements in sets are session-independent.

The session-dependency arising in my worksheet stems from solving some linear equations, the solution being giving in terms of some session-dependent indeterminates.

@Christopher2222: A moment ago I realized that my code is actually self-inconsistent, session-dependently speaking, because I read in from a file a previously saved expression which has been calculated in a different session. As this expression depends on some session-dependent indeterminates which are not read as well, because they were never saved alongside the expression itself, there is no reason to expect the worksheet to be self-consistent.