I see you reverted the IO layers, introducing an error.

>perl 689902.pl
UTF-16:Partial character at c:/Progs/perl588/lib/IO/Handle.pm line 413
+.
UTF-16:Partial character at c:/Progs/perl588/lib/IO/Handle.pm line 413
+.

>debug test.csv
-rcx
CX 0027
:
-d100 l27
0B04:0100  FE FF 00 73 00 65 00 F1-00 F3 01 59 00 2C 00 31   ...s.e...
+..Y.,.1
0B04:0110  00 32 00 33 00 2C 00 C5-01 42 00 E9 01 61 01 71   .2.3.,...
+B...a.q
0B04:0120  01 46 00 0D 00 0D 0A                              .F.....
-q
[download]

Note the last five bytes. You need either
:raw:encoding(utf-16) with \r\n
or
:raw:encoding(utf-16):crlf:utf with \n
for *both* input and output.

Also, the byte order is backwards — should be UTF-16le — but that doesn't matter for this discussion.

_utf8_on ($_) is NOT the way to go.

I used it without thinking because it's the complement of the (implicit) _utf8_off your module does, but utf8::decode is indeed better.

That said, the user is resonsible for the encoding/decoding of the data/fields, as CSV files have no way of telling that to the parser.

The data is already decoded by :encoding before being passed to the parser. The parser is told this via the UTF8 flag, but the parser simply doesn't check that flag (csv->bptr = SvPV (csv->tmp, csv->size doesn't have a corresponding SvPV (csv->tmp)).

The problem can be solved by simply dealing only with UTF-8. Use utf8::upgrade on all strings coming into the parser, and use utf8::decode on all strings coming out. The catch with that naïve method is the performance cost of dealing with UTF-8 even when it's not necessary.