1. If Mathematica and Maxima both complain about this, it is difficult to justify (other than through appeals to implementation details) Maple's behaviour.
2. Maple's inconsistency shown above by Joe Riel between eval and unapply+function evaluation is most definitely a bug.  They should be consistent with each other.
3. That expression evaluation and proc evaluation is also inconsistent (as shown by Alex Smith) is also problematic.  It should be very rare that this happens.
4. It is interesting to note that, by default, both Mathematica and Maxima use stronger normalizers for radical expressions than Maple does.  Why is Maple's so weak?!?

Of course, I am quite sure that one could find more complicated examples where Mathematica and Maxima would fail too.  It would be interesting to see exactly how they fail in those cases.  In other words, are all systems buggy in this fashion, with the only point of difference being how easy it is to demonstrate the problem?  If so, then in some sense the solution is simple: make the default zero-tester in Maple more powerful, to move the boundary to a spot similar to other systems.

If there is not enough space for the typical user to recognize that there is a multiplication going on, ie if the display of Maple's results will likely be mis-interpreted, then that's a plain bug.  If a user cannot understand, for very simple like this, Maple's output, then Maple is useless to that user.  As it is clearly Maplesoft's intent for Maple to be useful, it must be viewed as a bug.

You could consider actually showing what the 'correct' latex for these cases ought to be, in your humble opinion, and why.  I am not defending Maple's sub-optimal choices here, but you'll find that this task quickly gets very difficult.

The Maple kernel and library understand the ASCII Maple language just fine.  However, there are a whole bunch of oddities with the "graphical" version, which makes it look like Maple doesn't understand its own input.  Until those bugs are fixed, it is safest to use 1D input (see the Options menu). 

The Maple kernel and library understand the ASCII Maple language just fine.  However, there are a whole bunch of oddities with the "graphical" version, which makes it look like Maple doesn't understand its own input.  Until those bugs are fixed, it is safest to use 1D input (see the Options menu). 

In Haskell, it is very useful to be able to define the precedence (and associativity) of new operators.  It allows you to define all sorts of nice EDSLs [embedded domain specific languages] in a convenient way.  Rather like 'Logic' is a DSL for logic embedded in mathematics/Maple. 

People have also done some similar things with hygienic macros in Scheme.  I have not looked at the exact details of the technology, but C# 3.0 contains 2 embedded DSLs (one for XML, another for SQL) in a really nice way.

Last I knew, the kernel used yacc.  I have no clue what the Java interface uses.  I am guessing it's a hand-built parser.

I had alp = m-c defined in my session, as well as having renormalized E*x to x.  Sorry.  With those definitions, you should get the 3rd order ODE.

I had alp = m-c defined in my session, as well as having renormalized E*x to x.  Sorry.  With those definitions, you should get the 3rd order ODE.

When defining new operators in Haskell, you can also specify its associativity and binding strength.

The problem isn't parsing, that's is actually well-understood.  It is which parsing technology you use.  I don't think the really old stuff (yacc in particular) can do this.  But most modern parsing frameworks have no problems with this.

If you examine high printlevel output, you'll see that Maple has many different methods that actually 'get' this integral, but eventually refuse to give an output because they cannot ascertain that the answer is 'correct'.  Until you get to the MeijerG-based code, which is somehow a little less picky about this, and lets the answer through.

The most interesting thing is that there seems to be a number of places in earlier routines where letting the answer come through as a piecewise would not only be correct, it would be a lot faster!  I keep being forever disappointed by this antideluvian antipathy for piecewise.

In fact, the function might look complicated, but from the right perspective, it is extremely simple:

p := Pi*csc(Pi*alp)*((E*x)^m*hypergeom([m], [1-alp, 1+m], E*x)/(GAMMA(c)*GAMMA(1-alp)*GAMMA(1+m))
-(E*x)^c*hypergeom([c], [1+alp, 1+c], E*x)/(GAMMA(m)*GAMMA(1+alp)*GAMMA(1+c))):
de := PDEtools[dpolyform](y(x)=p, no_Fn);
          3
         d
  de := [--- y(x) =
           3
         dx

                    / 2      \
                    |d       |
        (m + c - 3) |--- y(x)|                         /d      \
                    |  2     |   (m + x - 1 + c - c m) |-- y(x)|
                    \dx      /                         \dx     /
        ---------------------- + -------------------------------]
                  x                             2
                                               x

        &where []

As long as c-m+1/2 is an integer, you will be able to find a nice closed-form for that expression. In other cases, you can reduce things down to the integral of the difference between 2 Bessel functions.

In fact, the function might look complicated, but from the right perspective, it is extremely simple:

p := Pi*csc(Pi*alp)*((E*x)^m*hypergeom([m], [1-alp, 1+m], E*x)/(GAMMA(c)*GAMMA(1-alp)*GAMMA(1+m))
-(E*x)^c*hypergeom([c], [1+alp, 1+c], E*x)/(GAMMA(m)*GAMMA(1+alp)*GAMMA(1+c))):
de := PDEtools[dpolyform](y(x)=p, no_Fn);
          3
         d
  de := [--- y(x) =
           3
         dx

                    / 2      \
                    |d       |
        (m + c - 3) |--- y(x)|                         /d      \
                    |  2     |   (m + x - 1 + c - c m) |-- y(x)|
                    \dx      /                         \dx     /
        ---------------------- + -------------------------------]
                  x                             2
                                               x

        &where []

As long as c-m+1/2 is an integer, you will be able to find a nice closed-form for that expression. In other cases, you can reduce things down to the integral of the difference between 2 Bessel functions.

.ico files used to have to be in the same directory as the executable.  So maybe they were put there because "that's how it used to be done"?

Did you make them as an SCR?  These seem like easy things to do, which might just get done if they are 'in the system'.