为何开发者未采用更简洁的枚举转字符串实现方案？

问题背景 #

我们有一个受版权保护的纯C头文件，定义了如下枚举类型：

typedef enum _API_TYPE { API_LEFT = 2, API_RIGHT = 4 } API_TYPE;

对应静态库中的枚举转字符串函数实现如下：

char* explainAPI(  
    _Inout_ char* sExplain,
    _In_ API_TYPE* enumerator
) {
    switch (*enumerator) {
    case API_LEFT:  sExplain = (char*)"API_LEFT ";  break;
    case API_RIGHT: sExplain = (char*)"API_RIGHT"; break;
    default:    sExplain = (char*)"  <???>  "; break;
    }
    return(sExplain)
}

我认为更简洁的实现应该是这样：

char* explainAPI(  
    _In_ API_TYPE enumerator
) {
    switch (enumerator) {
    case API_LEFT:  return (char*)"API_LEFT ";  
    case API_RIGHT: return (char*)"API_RIGHT";
    default:    return (char*)"  <???>  "; 
    }
}

因无法联系原作者，现向社区求助：原作者为何选择前者而非后者？

可能的设计考量 #

• 统一API风格：原静态库可能整套接口都采用"输出参数"的设计逻辑——所有需要返回数据的函数，都要求调用者提前准备好缓冲区，这个函数只是遵循了库内统一的编码规范，没搞特殊。
• 历史迭代遗留：这个函数大概率是从早期版本改过来的。比如最初的实现是把字符串拷贝到调用者传入的sExplain缓冲区里，后来为了简化直接返回字面量指针，但为了不破坏已经存在的调用代码，就保留了原来的函数签名没改。
• 预留扩展空间：原作者可能考虑后续要支持更复杂的场景——比如动态生成更长的描述文本，或者需要把结果写入调用者指定的特定内存区域（比如线程本地缓存、自定义缓冲区），保留_Inout_参数的设计，后续扩展时不用修改函数签名，兼容性更好。
• 适配老工具/框架：有些早期的调试工具、日志框架，要求必须接收一个可修改的字符串指针作为输出参数，原函数的签名可能是为了适配这类老工具的接口要求。
• const兼容性妥协：字符串字面量本质是const char*，强制转成char*在C++里是非法的，C里也属于未定义行为。如果最初设计是让调用者传入可修改的缓冲区，后来简化成返回字面量，但为了不改动签名才保留了参数——不过当前实现里直接赋值指针的做法，其实完全没用到传入的缓冲区，这应该是简化后的遗留痕迹。

内容的提问来源于Stack Exchange，提问作者Björn G. Kulms