@acer Thanks for your detailed comments.  I realize how plots:-display resolves/combines options from the various plot components, and in case of conflicting options it picks one.

That is the reasonable (and the only possible) behavior in general.  The light option, however, deserves to be treated as a special case since multiple light specifications need not be in conflict, but rather have additive effects.

This is not very difficult to do.  I have written graphing programs in OpenGL where multiple lights could be specified.  It may take a only a small tweaking of Maple's command parsing routines to permit multiple lights.

That works fine in Maple 2018.2.  I suggest that you upload your worksheet so that people can have a close look.

Acer and Carl, thanks so much for your comments.  It's the first time I am attempting Maple's Threads and Gird, and I did not know what to expect.

Following your suggestions, I switched from Threads:-Seq to Grid:-Seq and got my code working.  In my real application (not the skeleton one in the my question) I am getting a speedup by a factor or 3 on a quad-core CPU.  That's quite good.

@nepomukk As far as I know there is no simple way of doing that.

@José Goulart In the beam equation the E and I always occur together as the product E*I.  Therefore you don't need to define E and I speparately—define a single variable called EI whose  numerical value is the product of the values of E and I.  That way you will avoid encroaching on Maple's predefined value of I.

@nepomukk Perhaps this is what you are asking?

@Robotron1715 See if this works for you: zz.mws

@nepomukk I don't quite understand what you are asking, but perhaps this may help.

restart;
pde := diff(u(x, t), t, t)-c^2*(diff(u(x, t), x, x));
my_solution := -c^2*(d^2*a*sin(k1*(-c*t+x))/dx^2+2*d*a*k1*cos(k1*(-c*t+x))/dx);
pdetest(u(x,t)=my_solution, pde);

If the proposed solution in my_solution is correct, then pdetest() returns 0.

Verified the filename issue in Linux—same problem as you have described.

That reminds me of the occasional complaints that we read here about inability to load files whose names involve Danish characters. Could be due to the same underlying issue.

@nepomukk Maple can happily deal with expressions involving unspecified constants.  You don't need to assign them numerical values.

It may help to know more about what causes the solution to fail.  Perhaps K blows up at a certain point, or it oscilates too wildly, or beomes complex-valued.  Perhaps K itself may be modified in order to smooth out these issues instead of catching the problem through dsolve's events.

@ecterrab I am thinking that an alternative approach would be to restrict the effect to declared variables only.  To apply the effect to all variables, the user may call declare() with an empty argument.  This can help to avoid pathological cases like those noted by vv.

@ecterrab I can't tell whether your final remark is a genuine question or a rhetorical flourish but I will take it as a sincere question and provide a complete answer.

The second paragraph of the help page says "Typically, one declares functions by using declare(f(x, y, z)) with the result that f(x, y, z) is displayed as f ...".  In the third paragraph we have: "This scheme also displays all differentiation variables as indices".  The "all differentiation variables" is ambiguous. I read that as referring to the preceding paragraph and thus was misled to assume that it pertains to declared variables. That's all.

@Ramakrishnan You have described what we see in a worksheet.  But is that consistent with the documentation?  Is that intended or is it a bug?

@vv I see that behavior in a worksheet but is that consistent with the documentation?  The documentation says that variables specified in declare(...) are displayed differently.  It does not say that the other variables are affected as well.  Is the present behavior intentional?  Is it desirable?