(responding to Gianluca Gorni) That is right, DSolve does automatically assign un-involved variables as (constants), so your right, that was not the problem.
I see more issues I'd like to discuss about the one problem already mentioned, in PDE section of tests. https://www.12000.org/my_notes/pde_in_CAS/pdse4.htm#7
Mathematica solves (noting f can be f[t] or f[x] but generically f[x,t]):
a D[w[x, t], t] + b D[w[x, t], x] == f
DSolveValue[a D[u[x, t], x] + b D[u[x, t], t] == c, u[x, t], {x, t}] (* works *)
Taken from tests (see how conditions specify the form of w, not a value):
pde = D[w[x, t], t] + c*D[w[x, t], x] == 0;
ic = w[x, 0] == f[x];
bc = w[0, t] == h[t];
DSolveValue[pde, w[x, t], {x, t}]
C[1][(c t - x)/c]
DSolveValue[{pde, ic, bc}, w[x, t], {x, t}] (* no *)
Another way of expressing w (that will have solution(s) done by hand) is:
DSolveValue[{a D[f[x] h[t], x] + b D[f[x] h[t], t] == 0}, f h, {x, t}] (* does not work *)
The initial conditions for f h demand it have a particular form (which is neither a systems of equation and nor an initial condition). It may be true Mathematica doesn't allow it. However: I'm not an expert.
DSolveValue[a D[u[x, t], x] + b D[u[x, t], t] == c, x u, {x, t}]
In the above, x u is not a separation of x from answer u (changed form), it is u solution times x. Only "u" or "u[x]" are considered by DSolve.
DSolveValue[{a D[u[x, t], x] + b D[u[x, t], t] == 0, u[x, t] == -((b x C[2])/a)}, u[x, t], {x, t}] (* no *)
The above may be solvable, but Mathematica does not "like" over-determination (being told what u is as a condition of solving for u).
Mathematica cannot be called "incorrect" or "incapable" because it solves problems a different way.
I'll also say that seeking to get a particular form:
w[x,t]==f[x-ct]/;x>ct
as a "result of DSolve", is unreasonable. Because there could be other forms with other assumptions. In Mathematica to get a particular form you must try to solve ONLY what would yield only that form to get that form, not something much more general which could involve things such as (what realm constants are in, when replacements for conditions are to apply (during reasoning or to replace constants), etc). In Mathematica you can change forms (using mm library) to shift form before or after DSolve, but not during. It makes sense that DSolve's solver takes province of form, taking routes that have less doubt, to to provide an accurate reliable answer.
(repeated from post above): maple was given a "check" for returning an expression no one has argued tet as (being correct in all cases, or being a weak answer, or perhaps incorrect). Is it true the (by hand solution) is invalid when the laplace cannot be solved? Or is that bogus?
I comment and like the topic because I'm learning it and would like to know more.
4.7 First order wave PDE, with initial and boundary conditions (discussed above)
4.17 General solution of a ?rst order nonlinear PDE (same as discussed above, form of w specified in initial conditions, though i do not show a rewrite of it)
4.19 ?rst order PDE of three unknowns. Works - test maked fail incorrectly.
Mathematica does claim DSolve[eqn,y[x1,x2,...],{x1,x2,...] (noted by another post, mm's NDSolve was stated as "better"). that's a win for Maple (assuming all answers are not bogus).
DSolveValue[(y - z) D[u[x, y, z], y] + (z - x) D[u[x, y, z],
y] + (x - y) D[u[x, y, z], z] == 0, u[x, y, z], {x, y, z}] (* works *)
C[1][x][y + z]
(The Mathematica book explains GeneratedParameters controls the form of generated parameters; for ODEs and DAEs these are by default constants C[n] and for PDEs they are arbitrary functions C[n][...]) Now a good question: is Maples answer as "good"?
For tests there is a "cheat" to expose: it is that 'build' is pumped as arg to pdsolve and is counted as "correct answer". "build - (optional) try to build an explicit expression for the indeterminate function, no matter what the generality of the solution found" (it's obviously a weak / not strong solution so calling it a win, even if by hand it is the same, is improper, since it is only "right" by retrospect comparison)
"build" was used in 3 test problems in the PDE Mathematica v. Maple tests section
(((errata: however my first tests I got an immediate fail (not a timeout) on both solved problems above 4.7 4.19, and after resetting kernel (to be sure) a "long timeout" while the kernel loaded (which happens any time an error forces Quit[]). So I'm guessing the test went astray somewhere and the reasons why were not investigated well. Mine went astray because I had been solving ODE and, despite clearing normal vars, had "issues" with definitions I didn't know of (perhaps upon C[1]). (there is a mm option to insure C is unique across all answers in kernel btw)))