@acer 

Indeed, continuity on the real axis is an important criterion. In practical terms, most definite integrals are made on an real interval, and the main problem of the FTOC method lays in handling these discontinuities on the real axis. Maple and other CAS are only partially succesful in this area, and several interesting posts/blogs were posted here and elsewhere on this precise issue:

Discontinuous Antiderivatives

Funny Behavior With Int

A Perilous Tale Of Definite Integration

Mathematica and the fundamental theorem of calculus

Some advances were made for a class of integrands, in papers by David Jeffrey and Albert Rich, as Jacques has mentioned here. And this state of the art means roughly that what you can get is moving the discontinuities away from the real axis to somewhere else in the complex plane.

The matter with a piecewise constant is the location of the jumps. Either you exclude those points or you include them but consider an integrand that differs from the original one by Dirac terms with support on those points. In this regards, both f1 and f2 are identical as the imaginary part of both has two jumps. Adding a (true) imaginary constant may change the region where this imaginary part vanishes, but this is largely irrelevant as the primitive/antiderivative function is actually a class under addition of a constant. And the problem of the FTOC algorithms is with jumps, not with true constants.  

In my opinion, both simplicity and continuity on the real axis should be criteria used to decide between alternative primitive/antiderivative functions. In this case, the real part of these functions differ by a constant and both functions have a piecewise imaginary constant, just with jumps located at different points:

f1:=-arctanh(1+3*x):f2:=1/2*ln(x)-1/2*ln(2+3*x):
plot([Re,Im]( f1), x=-1..1);
plot([Re,Im]( f2 ), x=-1..1);
plot([Re,Im](f1-f2), x=-1..1,-2..2);

So, I do not find that the continuity criterion selects any of them. Then, the simplicity criterion tells that the arctanh form is better.

@acer 

I agree, this difference in default behavior is a serious problem, though I know that its solution is utopian. The behavior should be uniform and selectable by the user. Probably, by an environment variable playing the role of dsolve's convert_to_exact option, but for all the system. In my choice, it would be set to true (avoiding in particular all those problems with mixed situations).

@JacquesC 

I dislike this design and disagree with the source of the problem. The problem is rather the particular implementation where using the decimal notation is made to imply computation in the float domain, despite that they are two quite different things. The fact that it is easy to describe, and easy to deal with for CS purposes, does not imply that everybody else using 0.3 is sloppy or confused or not properly educated about whether it is meant exactly 3/10 or an approximation to 0.300001. A mathematical system should not make guesses about the user's purpose or knowledge. If the user intention is using 0.3 as an alternative (decimal) notation to the fraction notation 3/10, he/she should be given the means to comunicating this information to the system, so that it proceeds accordingly in the computations by selecting algorithms for "exact" quantities. And also the user should be given the choice of the output mode of such computations (in fraction or decimal notation).

In short, it is the system that should be adapted to user's needs, not the other way round.

@pagan 

Also, I would find even more simple to use a single over command for putting accent-like characters on top, as we use in TeX. Something like:

over:=proc(x,y)
nprintf("#mover(mi(%A),mo(%A))", x,y);
end proc:

over("ζ","^");
over("ζ","~");

@pagan 

Also, I would find even more simple to use a single over command for putting accent-like characters on top, as we use in TeX. Something like:

over:=proc(x,y)
nprintf("#mover(mi(%A),mo(%A))", x,y);
end proc:

over("ζ","^");
over("ζ","~");

@pagan
Also, comparison of the character boxes, by coloring them, may help visualizing the convenience of the combination:

`#mover(mi("ζ",mathbackground="yellow"),mi("~",mathbackground="green"))`;

`#mover(mi("ζ",mathbackground="yellow"),mi("˜",mathbackground="green"))`;

@pagan
Also, comparison of the character boxes, by coloring them, may help visualizing the convenience of the combination:

`#mover(mi("ζ",mathbackground="yellow"),mi("~",mathbackground="green"))`;

`#mover(mi("ζ",mathbackground="yellow"),mi("˜",mathbackground="green"))`;

The TypeMK code of the 2-D input generated by Michael's recipe is (ready to be executed in 1-D):

Typesetting:-mover(`Typesetting:-mrow`(`Typesetting:-mi`("ζ", italic = "false", 
mathvariant = "normal")), `Typesetting:-mrow`(`Typesetting:-mo`("~", 
mathvariant = "normal", fence = "false", separator = "false", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.1111111em", rspace = "0.1111111em")), accent = "true");

while the TypeMK code for the output it generates is:

Typesetting:-mover(`Typesetting:-mi`("ζ", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`("˜", mathvariant = "normal", fence = "unset", separator = "unset", 
stretchy = "unset", symmetric = "unset", largeop = "unset", movablelimits = "unset", 
accent = "unset", lspace = "0.0em", rspace = "0.0em"), accent = "false");

Note the differences. In particular, the usage of "~", instead of "˜" would have given much better results.

The TypeMK code of the 2-D input generated by Michael's recipe is (ready to be executed in 1-D):

Typesetting:-mover(`Typesetting:-mrow`(`Typesetting:-mi`("ζ", italic = "false", 
mathvariant = "normal")), `Typesetting:-mrow`(`Typesetting:-mo`("~", 
mathvariant = "normal", fence = "false", separator = "false", 
stretchy = "false", symmetric = "false", largeop = "false", movablelimits = "false", 
accent = "false", lspace = "0.1111111em", rspace = "0.1111111em")), accent = "true");

while the TypeMK code for the output it generates is:

Typesetting:-mover(`Typesetting:-mi`("ζ", italic = "true", mathvariant = "italic"), 
`Typesetting:-mo`("˜", mathvariant = "normal", fence = "unset", separator = "unset", 
stretchy = "unset", symmetric = "unset", largeop = "unset", movablelimits = "unset", 
accent = "unset", lspace = "0.0em", rspace = "0.0em"), accent = "false");

Note the differences. In particular, the usage of "~", instead of "˜" would have given much better results.

@PatrickT 

Indeed, checking and unchecking the menu option "Display Examples with 2D math" toggles back and forth between 2-D input and 1-D input in the Example section of the help pages. I do not know why such a tool is not available for using elsewhere.

@PatrickT 

Indeed, checking and unchecking the menu option "Display Examples with 2D math" toggles back and forth between 2-D input and 1-D input in the Example section of the help pages. I do not know why such a tool is not available for using elsewhere.

I think yes, it would be nice and feasible. Actually, the Standard GUI help browser has a facility for toggling between 1-D or 2-D input in the Examples section: View >  Display Examples with 2D math.

I think yes, it would be nice and feasible. Actually, the Standard GUI help browser has a facility for toggling between 1-D or 2-D input in the Examples section: View >  Display Examples with 2D math.

@Kamel Boughrara It is possible in Classic GUI and in Standard GUI with 1-D input. For 2-D input the best workaround, probably, is exporting the worksheet to a text file and search there.