inet_aton is provided by Socket, and encode_utf8 is provided by Encode. I left a few obvious headers out since they weren't relevant.

The headers can't possibly be irrelevant if the Perl script doesn't compile without them. And there's nothing intrinsically obvious about them either. If there were, then perl wouldn't need the programmer to use them. As it happens, I knew that encode_utf8() is from the Encode module because I'd used it before, but I didn't recognize inet_aton() because I'd never used the Socket module before.

If you post something on PerlMonks to make a point, you can't neglect to make the point. Otherwise, you're just arguing obscurely and unhelpfully.

In all four cases, print outputs the four bytes C3 A9 C3 AB because in all four cases, the string passed to print was "\xC3\xA9\xC3\xAB".

This is the point you neglected to make. In your post, you didn't state the point explicitly, and you also didn't include the output of the Perl script you intended to demonstrate the point you were trying to make. You left it as an exercise for the reader to run your script, which we've established doesn't compile as posted.

PerlMonks is now littered with threads much like this one. A monk comes to the Monastery seeking clarification about how character encodings and Unicode work in Perl—particularly for help understanding their myriad subtleties. Instead of getting clarification, the monk just gets more confusing details, oftentimes within a torrent of rhetorical arguments and even flame wars. You're involved in many of these discussions, and I think your explanations usually lead to more confusion rather than to greater clarity. I don't doubt that you're 100% correct in every gory technical detail. I just don't think you do an effective job of translating the technical facts from your complex mental model of them into clear information about the topic that ordinary Perl hackers can use to help them write Perl scripts.