@Carl Love 

At this moment, it is not so clear to me that this bug is located in the symbolic integration of such expressions. A preliminary observation is that the calls are actually been made for the export MTM:-int, but this is not the cause per se. The output of tracelast after the statement int(dd, x = 0 .. L) show the actual calls to MTM:-int and later to int, and both, executed in a fresh session produce a result. So, it looks like something else gets messed as a consequence of the previous computations. 

@Carl Love 

Perhaps, it would be easier to remember a command that creates a subindexed object, as Mathematica's Subscript, like with this toy procedure (for the Standard GUI only):

sub:=proc(x,y)
nprintf("#msub(mi(%A),mn(%A)))",x,y);
end proc:

sub(mu,"01");

@itsme 

By the way, the OP's Grid:-Map statement (with collon terminator) returns for me, on Linux 32-bit (and default max java heapsize), "Error, (in Grid:-Launch) deadlock detected" in Maple 18 and no ending computation in 2015. So, chances are that differences in handling memory between 32 and 64-bit may produce an impact at this scale of computations.

@tomleslie 

The facts are that after the requests for more openness about reported bugs cited above, made in years 2007 and 2008, feedback posts appeared here about Mapleprimes bug reports for Maple 13 (2009) and Maple 14 (2010). No equivalent posts were made later as far as I know.

An interpretation of these facts is that these feedback posts were a reaction to previous requests. This reaction was in the positive direction of more openness. The "size" of this reaction, i.e. the degree of openness, was small, in proportion to the small "intensity" of the requests from the user community. These feedback posts were no longer provided for later versions as "pressure" from the user community was not kept.

if this interpretation were true, it would mean that individual users might have a larger influence on such issues if agreement were reached to act in a more coordinated fashion, in favour of common interests, even with tiny buying power each.

@spark1631 

See this thread towards its end, and the linked (sub)threads.

@Preben Alsholm 

Well, I have the feeling that we have just scratched the surface of this issue. Meaning, in particular, that that difference in behavior between the toy procedures pp and qq is more intriguing than illuminating. But yes, I agree that a SCR is needed. May be that there are several bugs around!

@ 

In regards to those issues of development and documentation, you might be interested in reading e.g. here about the maintainance problem - note that the logical order of that thread was upset in the transition to Mapleprimes 2.

@Preben Alsholm 

It may be more complicated. Indeed, I have checked that turning back the name a to local after becoming global in the repetition statement does not solve this problem per se. But you are showing also that there is an issue with an indexed name being assigned (becoming a table entry and producing a change of evaluation rule):

> pp:=proc(i,j) local dm; dm[a]:=max(i,dm[a]); dm[a]:=max(j,dm[a]) end proc:
> pp(1,2);
Error, (in is/internal) too many levels of recursion

> qq:=proc(i,j) local dm; dm:=max(i,dm); dm:=max(j,dm) end proc:
> qq(1,2);
                                   max(2, dm)

PD. Apparently, after debugging, the failure of this procedure pp occurs in the line 33 of `is/internal`:

33   if not type(obj,'last_name_eval') and member(true,map(assigned,
     select(type,indets(obj),And('name',Non('last_name_eval'))))) then

traced as:

...
{--> enter is/internal, args = dm[a]-2, real
                      is/internal(dm[a] - 2, real) := FAIL
<-- ERROR in is/internal (now in is) = "too many levels of recursion"}

In all, it seems like the evaluation level play an important role in this issue. Indeed, such kind of assignments produce recursion at top level:

> dm[a]:=max(i,dm[a]);
Error, recursive assignment

And probably, something similar occurs when you wrap with eval within the procedure.

@tomleslie 

Yes, I agree that this bug deserves a SCR.

@itsme 

Yes, I know of those problems. But little is lost by just trying. Moreover if the OP wants a fully vectorial export...

@Preben Alsholm 

No actually there is a bug in the code of the procedure `DEtools/convertsys`. Note that e.g. using p(t) in place of a(t) produces the expected result, and both are equally "unknown". The problem, to make it short, is that this procedure uses a local name a, and at some point (in a repetition statement) this local a become global, thus clashing with the a of the equation and finally generating a recursion error. 

@Carl Love 

Note that with simplify(...,symbolic) branch cut problems may occur:

> f:=ln(1+sqrt((m+1)/m)):
> Int(f, m):
> simplify(%, symbolic):
> F:=value(%):
> f1:=diff(F,m):
> simplify(f1-f) assuming m>0;
                                       0
> simplify(f1-f) assuming m<0;
                        1/2     1/2
- (-ln(-I (m I - (m + 1)    (-m)   )) m I
                           1/2     1/2          1/2     1/2
     + ln(-I (m I - (m + 1)    (-m)   )) (m + 1)    (-m)    + ln(m) m I
                    1/2     1/2                              1/2     1/2
     - ln(m) (m + 1)    (-m)    - ln(-m) m I + ln(-m) (m + 1)    (-m)
                       1/2     1/2
     + ln(-m + (-m - 1)    (-m)   ) m I
                       1/2     1/2         1/2     1/2
     - ln(-m + (-m - 1)    (-m)   ) (m + 1)    (-m)
                           1/2     1/2
     - ln(-I (m I - (m + 1)    (-m)   )) I + ln(m) I - ln(-m) I
                       1/2     1/2         1/2   /         1/2
     + ln(-m + (-m - 1)    (-m)   ) I) (-m)     /  ((m + 1)
                                               /
                1/2     1/2
    (m + (m + 1)    (-m)    I))

@Chris 

It could be explained as a lesson. If you use software written by somebody else, it will work after the author's mindset. So, if you want it to work as you like or need, you might have to write it yourself.

@tomleslie 

I am free of such preconceptions. If I know that something else is better than Maple in some area, I say it here or elsewhere, no problem.

In regards to comparative reviews, there has been several threads here in the past.

@roman_pearce 

But you see that there is a conflict here. In interactive usage, where expressions are not that large, the efficiency of the human-machine interaction becomes much more important than purely computational performance. So, in this context, a design choice that might be good for high-end computations becomes bad.