The default 50 would be fine only on 16-bit machines, which are out of use since long. But even in that case, those machines had more limited precisions for the floating points, and number would be complied most probably only as a 32-bit float (still requiring often software emulation), so the maximum string length 50 is also overkill. Only on those machines you would want to save some bytes on the stack, so you would reduce 50 to just 32 and it would still mich be large enough for 32-bit floats; may be "long double" could be supported by (slow) libraries but the compiler would just compute at most 64-bits like for "double", four which a 32-byte buffer (including the null terminator) is still enough. As these specialized types of small machines have lot of other limitations, "luaconf.h" would need to be tweaked specially to compile Lua on them (e.g. for small microcontrollers driving simple hardware bots or tools not requiring high-speed control).
50 bytes is wrong for all cases. 48 bytes would be better and would still work (the extra 16 bytes on the stack are for the one or two parameters of the function call and possibly one for the returning point or a save slot ion the stack for a register that will be used by inlined functions). Still there won't be any alignment problem with today's 32-bit or 64-bit machines, or newer 128-bit machines (or existing 64-bit machines like x64 or ARM64 with 128-bit vector extension that could have hardware support integrated in their ISA).
The value "50" must just have been a rough estimation for humans and makes no sense, it just adds extra complications for the compilers and possible causes of bugs (or could prevent some optimizations to occur). Let's remember that Lu very frequently performs conversions between numbers and strings: this should be efficient without extra complication, and all optimizer hints should be usable (notably compilers could use inlinable intrinsics with more aggressive register allocation and serialized instructions or vector instructions, rather than using the stack and function calls if it can. This can boost a Lua program quite a lot in frequent hotspots: these number<->string conversions are such hotspots in Lua.
