-Several new functions for handling Unicode have been added to the API:
-C<L<perlapi/is_strict_utf8_string>>,
-C<L<perlapi/is_c9strict_utf8_string>>,
-C<L<perlapi/is_utf8_string_flags>>,
-C<L<perlapi/is_strict_utf8_string_loc>>,
-C<L<perlapi/is_strict_utf8_string_loclen>>,
-C<L<perlapi/is_c9strict_utf8_string_loc>>,
-C<L<perlapi/is_c9strict_utf8_string_loclen>>,
-C<L<perlapi/is_utf8_string_loc_flags>>,
-C<L<perlapi/is_utf8_string_loclen_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_loc_flags>>,
-C<L<perlapi/is_utf8_fixed_width_buf_loclen_flags>>.
-
-These functions are all extensions of the C<is_utf8_string_*()> functions,
-that apply various restrictions to the UTF-8 recognized as valid.
+The functions C<utf8n_to_uvchr> and its derivatives now return the
+Unicode REPLACEMENT CHARACTER if called with UTF-8 that has the overlong
+malformation, and that malformation is allowed by the input parameters.
+This malformation is where the UTF-8 looks valid syntactically, but
+there is a shorter sequence that yields the same code point. This has
+been forbidden since Unicode version 3.1.