>Could do, but I think we'd be better to try to figure out what is
>optimal rather than proliferating options.
--x-12-arima behavior tells than even they
use a different algorithm, in practice the
behavior of their estimates is indistinguisheable
from my arima3

Finding a good non-transforming area could
require months of investigation.
At the other hand, a new option requires 
only several minutes of your work.
Please, take into consideration the 
following items for arima to be robust
with respect to convergence:
1) mimic a good pattern:
there are a lot of smart guys in US
Census Bureau; they preferred to make
theirs arima in such a way that for all
time I found literally only a couple
examples when arima ... --x-12-arima
fails to converge.
And I am sure that being smart they
do have  reasons to comply the way
they do

2) model selection
(i) we have to decide whether to
take logs (or general Box-Cox transformation)
for the original y series
(ii) we have to select  d = 0, or d = 1, or d = 2
using a unit root test
(iii) we have to select D = 0, or D = 1
using a seasonal unit root test
(iv) we have to decide whether to include
constant to the model
(v) we have to select the admissible region
for p,q,P,Q
Every one of the stages above can give
type I/II error
This means that after stage
(vI) select p,d,P,Q using some IC
we can come up with a
mis-specified model.
All this tells that in practice the
majority of models we estimate are
mis-specified. A mis-specified model
must be estimated and mis-specification 
must be established by standard means:
1) bad polynomial roots
2) autocorrelation
And not the ather way around.

3) marketing consideration
The first thing of the representative user
after a non-convergence case is something
of a kind "bad soft"
Once more: non-convergence is a sub-optimal
mean for bad specification diagnostics.
The standard means are to be preferred:
the  first - get estimates
the second - to look at bad roots and
Q'-statistics p-value

Oleh