Thank you guys for putting down my contribution. I think I will spend some time thinking over whether I want to make further contributions to this forum in which there seems to be going on an alfa male fight for intellectual supremacy, a behaviour which to me is quite dispiriting.

I do not know, and I do not care.

The following code (inspired by the code of Robert Israel), which probably can be improved upon (please feel free to do so), seems to solve the first issue of mine, even in the more complicated case as mentioned in my post above:

ReIm := proc(x)
   local i,j,y,addends;
   y := expand(x);
   if type(y,`+`) then
      addends := op(y);
      for i from 1 to nops([addends]) do
      for j from i+1 to nops([addends]) do
         if addends[i] = +conjugate(addends[j]) then
            return ReIm(y + 2*Re(addends[i]) - addends[i] - addends[j])
         elif addends[i] = -conjugate(addends[j]) then
            return ReIm(y + 2*I*Im(addends[i]) - addends[i] - addends[j])
         end if
      end do;
      end do;
      y
   else
      y
   end if
end proc:

Oh, that is just so cool. It completely solves the second issue of mine (if evalc is replaced by expand), and much more, of course. Thanks so very much. I cannot help wonder why the functionality you here provide is not part of standard Maple.

Note added: This post and the post above by Robert Israel crossed each other, so this post does not address his contribution. Thank you all for your contributions, but I am still confused - or rather, now I am even more astounded by the way Maple behaves than I was prior to my original post. First of all, I have a hard time understanding why Maple does not know that Re() and Im() act distributively with respect to + and -. If Maple was aware of that, then, I suppose (cannot be too sure, obviously), the second issue would immediately be resolved, even without the use of evalc(). Second, I am shocked to see that

assume(x::complexcons):
evalc(x + conjugate(x));
evalc(x - conjugate(x));

gives 2*x and 0, respectively. For instance for x = 1+I, which is indeed of type 'complexcons', that is just plain wrong. What is going on? So even though initially I was enthusiastic about using the type 'complexcons', because it seemed to resolve the second issue of mine, I have lost confidence in them. On the positive side, though, it seems that simplify() works where evalc() fails: For instance (as the post by Thomas Madden made me aware)

assume(x::complex):
+1/2*simplify(x + conjugate(x));
-I/2*simplify(x - conjugate(x));

does indeed give Re(x) and Im(x), respectively, providing a workaround for the first issue in the form it was posed. However, I would also like it to work for more complicated expressions: For instance, for

assume(x::complex,y::complex):
+1/2*simplify(x*conjugate(y) + y*conjugate(x));
-I/2*simplify(x*conjugate(y) - y*conjugate(x));

(which mathematically is of the same form) I would like it to yield Re(x*conjugate(y)) and Im(x*conjugate(y)), respectively. The reason why this is important to me is that I have (in quantum calculations of mine) expressions which are long sums of terms of this particular form.

Thanks guys for your efforts.

Thanks guys for your efforts.

Thanks for clearing up that misunderstanding of mine.

No need to use structured types, obviously. Thanks a lot!

No need to use structured types, obviously. Thanks a lot!

That, I suppose, is what happens when one (that is me) rolls back to Maple 9.5.

That, I suppose, is what happens when one (that is me) rolls back to Maple 9.5.

Thanks a lot for that information, especially concerning the way Java is installed. Looking in the Maple installation folder I can see a "java"-subfolder which I suppose is the one in question.

Thanks for your reply. I almost never double click files, but instead open them from within the programs themselves (a bit more elaborate, but presumably foolproof). So, assuming that my shortcut icons, as mentioned by Mariner above, have been properly set up [if I am not able to do that, then maybe I should apply for a new brain :-)], there should be no problems there. I think I was also worrying a bit about interference between the Java Runtime Environments of different versions of Maple. But I suppose (knowing almost nothing about Java, and definitely nothing about how Java is used inside Maple) that they are kept completely apart, or what?

I was worrying, I suppose, because other Windows programs, when installed, seem to replace or update their older versions.