Whatever in the world do you want it for, anyway?

Obtaining knowledge of the storage requirements for a piece of data does not seem such an unusual requirement to me. Whether it is for sizing a buffer for interfacing to a C (other) language library; or for length-prefixing a packet for a transmission protocol; or for indexing a file; or any of a dozen other legitimate uses.

Indeed, given that this information is readily & trivially available to Perl:

#! perl -slw
use strict;
use Devel::Peek;
use charnames qw( :full );

my $text = "\N{LATIN SMALL LETTER E WITH ACUTE}";
print length $text;

Dump $text;

__END__
C:\test>junk.pl
1
SV = PVMG(0x27fea8) at 0x237ab8
  REFCNT = 1
  FLAGS = (PADMY,SMG,POK,pPOK,UTF8)
  IV = 0
  NV = 0
  PV = 0x3c78e8 "\303\251"\0 [UTF8 "\x{e9}"]
  CUR = 2
  LEN = 8
  MAGIC = 0x23c648
    MG_VIRTUAL = &PL_vtbl_utf8
    MG_TYPE = PERL_MAGIC_utf8(w)
    MG_LEN = 1
[download]

the absence of a simple built-in mechanism for obtaining it seems both remiss and arbitrary.

But then, this is just another in a long list of reasons why the whole Unicode thing should be dumped in favour of a standard that throws away all the accumulated crude of transitional standards and yesteryears physical and financial restrictions.

Given the cheapness of today's ram, variable length encodings make no sense given the restrictions and overheads they impose. And any 'standard' that means that it is impossible to tell what a piece of data actually represents without reference to some external metadata is an equal nonsense.

With luck, the current mess will be consigned to the bitbucket of history along with all the other evolutionary dead ends like 6-bit bytes and 36-bit words.