Okay so first of all, this is already supported in the RAM macro. You press record, type out what you want, and press record again. Then you press play to send what you recorded. That is available and working.
I assume what you're talking about is recording macros on the fly to non-volatile memory so it can survive a power loss. Let's talk about that.
Right now, M1 through M14 are stored in Flash memory with the program and layer maps. The macros are entered into the GUI, then packed into the macro buffer, then programmed. They get packed in one after another so it doesn't matter how long or short any individual macro is, as long as all of them together fit into the reserved space for macros. When you press a M? key, it looks up the start index of that key's macro and just reads scancodes out of flash until it hits a terminator.
I like this approach for a few reasons. The GUI makes changing macros is low effort, and you can see what you're scripting so no typos. You can also add things to the macro that can't be typed.
Now, let's consider how this would be done on the fly. They keyboard can't reprogram its own Flash memory, so your only option is EEPROM. So, we reserve a part of EEPROM for the config settings that are already there, then we use the rest for macros. Since these macros can be changed at any time, I can't pack them in tightly like in Flash. The AVRs have very little RAM so I'll not be able to re-organize the macro buffer when new macros are recorded. Instead, I'll have to split it up equally and restrict the max length of any individual macro. Depending on the number of macros we try to fit, this could be unreasonably short.
But say we make a compromise and implement it. Now you can record a permanent macro the way you described. Maybe you make a mistake and have to redo it 20% of the time, but that's not such a big deal. However if you are constantly re-recording macros to use temporarily, you now have to worry about EEPROM wear-out and you could have just used RAM instead which has no wear-out. If you record it once and don't change it for months, you could have just used Flash. The use case for keyboard-programmable non-volatile macros is narrow.
Okay, so that's why the code is currently the way it is. But I understand that people want this and TMK already does it, so I'm willing to give it a try.
But let's plan it well. How many macros should be this way, and what is the required max length? I need to get requirements before I can make a design.