Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Here it's an example script:

<?php

    echo phpversion();

    $original = 'Hello' . chr(240) . 'World';
    
    $result = iconv('EUC-JP', 'UTF-8//TRANSLIT', $original);

    echo $result;
?>

IMO, it should return:

"Hello?World" (or, if I'm not wrong, "Hello World")

instead it returns "Hello" and stops, where the TRANSLIST 
mode should make it arrive to the end.

Notice: iconv(): Detected an illegal character in input string
Even though the character might be legal, it's up to libiconv to decide if it's legal or not and PHP can't change that.

Thanks, I agree!

But shouldn't the //TRANSLIT mode modify such behaviour and 
allow the conversion to continue? If not, perhaps some minor 
modification to the manual page could help, because it seems 
that both the //TRANSLIT and //IGNORE modes continue with the 
conversion and that's not true for the //TRANSLIT mode.