@bot
So I have a couple of thoughts on this. My experience lies in using something like this in my profession. One of my job responsibilities is machine tool(CNC) programming. I have set up a couple of machines that automatically engrave serial numbers/dates/etc. The easiest implementation of serial numbers that I have come across is as follows.
The main machining program calls a sub routine for each line that you want to machine. You pass the numbers/digits you want to engrave into the sub via parameters in the sub call. You also specify XYZ start locations, and font size as globals right before calling the sub. To control the serial number we just increment a global variable for each program call and write an updated value to that global variable after the engraving has finished. The example of this would be that we always want to engrave the string ABC000, but we update the 000 lines of the string every time we run the code.
On the CNC equipment the program for engraving is a program that just lives on the control. For 3D printing I could see this being an issue. I would think we want the slicer to build a sub program that are already the appropriate size/orientation and then use program calls to perform the correct action(the "pre sliced" alphabet mentioned above). (A better solution would be for the slicer to input these at the "bottom" of a program, to GOTO command referred to in the @bot first post here). The relative positioning seems like the best bet for this to keep it simple (I hate relative positioning as it causes machines to crash, but I think its the best use for it in this case).
In this case the slicer will probably have to call the individual letter/number islands multiple times for each digit at each layer. Because this is the case I don't think it makes sense to write a ton of code for RRF to do much a bunch of work. I think most of it lies in the slicer.