1. При раскодировке неправильного UTF-8 неверную часть желательно заменить символом - заместителем, а потом перезапустить чтение. А потом может понадобиться этот символ обратно из UTF-32 перегнать в UTF-8. В идеальном мире кодировка/раскодировка вообще должна быть без потерь, чтобы любая последовательность байт (кроме 0) преобразовывалась бы в UTF-32 и потом обратно, но это уже мои домыслы/фантазии. Не знаю, осуществимо ли это, делал всё как обычно в спешке и в такие глубины не лез. Но на практике необходимо ожидать, что любые последовательности байт, в т.ч. и некорректные, обязательно придут к нам на вход, и вести себя как-то так, чтобы дать пользователю понимание, что случилось, но при этом нельзя сразу падать, поскольку это лёгкая мишень для атаки.

2. Нет, на одной кодировке по историческим причинам остановиться нельзя. Т.к. уже есть модуль Texts с 32-битным символом (который пока что представлен тупо числом, что крайне неудобно со многих сторон), и есть обмен данными с Windows, где используются 16-разрядные символы. Ну а UTF-8 тоже уже есть во многих местах. Такова суровая жизнь разработчика операционных систем.