On the other hand, code might (for example) look at the return from RvalContainerPrimitiveAsString and decide that an empty value, or the value "{ }", or something similarly vacuous, should be handled differently, e.g. they decide to set result to NULL (or, indeed, to "{}" or some slightly different representation of the same vacuous answer); or they might use one variable result to collect several returns from the function, in a loop body, handing each of the strings off to something else in turn, but breaking out of the loop when some condition is met that leaves the out-of-loop code wanting to look at the last return.

In any case, gcc doesn't like that second const: it says <code>
warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
</code> and it's entirely right: the qualifier doesn't actually prevent me from writing <code>
const char *result = RvalContainerPrimitiveAsString(...);
</code> This is entirely legitimate, notwithstanding that the function claims to return a <code>const char* const</code>  After all, what difference would you expect the const in <code> const int four(void) { return 4; } </code> to make ?  (I have verified that the only thing gcc thinks is bad about <code>
static const char* const vacuous(void) { return "vacuous"; }
int main(void)
{
  const char* handler = vacuous(); /* totally legal */
  return handler[0] == 'v';
}
</code> is the second const about which it gives the warning I quoted above.)

The one difference the second const could make is to prevent me using RvalContainerPrimitiveAsString as a tool function to some API that expects a function taking the same parameters and returning const char* - but, with any luck, that's unlikely to be a way we'll want to use the function.
My preference is to avoid the warning from gcc by skipping the spurious second const.