In today's teleconference, JeanHeyd suggested that the
"pointer + length" interface would allow to pass nullptr
for the output length, allowing the user to assert
"there is enough space", which, in turn, allows to forego
range checking during transcoding.

At least the version of iconv on my current Ubuntu
system does not offer precedence for these semantics;
passing nullptr for the output length just crashes.
Test case:

#include <iconv.h>
#include <stdlib.h>

int main()
{
  iconv_t cd = iconv_open("utf-8", "utf-8");
  char in[] = "abcd";
  char *pin = in;
  size_t nin = 4;
  char *pout = (char*)malloc(100);
  size_t nout = 100;
  size_t n = iconv(cd, &pin, &nin, &pout, nullptr);
}

This behavior is consistent with the description in
the man page, where no mention of special handling
of nullptr length arguments appears.
Plus the POSIX specification agrees:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html

I'd also like to point out that interfaces that
assume "there will be enough space" are prone to
misuse, admitting buffer overflows. I'd also
like to point out that the perceived run-time
overhead of the extra length check is partially
mitigated by

 - the necessity to check the length pointer for nullptr
and branch to a special implementation

 - in a [begin, end) iterator range implementation,
the ability to determine the available space and omit
some or all length checks if ample space is provided.

In short, I believe the core interface should treat in
[begin, end) iterator ranges, where "begin" is updated
by the function. If that doesn't materialize (for whatever
reason), I expressly do not want thin decorators to
be standardized, ballooning the number of functions even
more.

Jens