API Set 是什么？
想象一下，Windows就像一个大型图书馆，而API Set就是这个图书馆的索引系统。但这个索引系统非常特别：它是直接内置在Windows加载器中的"虚拟目录"。
// 一个典型的API Set映射示例
api-ms-win-core-memory-l1-1-0.dll -> kernelbase.dll
api-ms-win-core-file-l1-1-0.dll -> kernelbase.dll
为什么还要保留物理文件？
这就问到点子上了！这些物理文件存在主要有三个原因：
1.向后兼容 想象你有一台老式DVD播放器，它只认DVD，不认网络流媒体。这些物理DLL文件就像是为老系统准备的"老式播放器"。
2.调试支持
// 开发者调试时可以看到这样的加载路径
LoadLibrary("api-ms-win-core-memory-l1-1-0.dll")
// 而不是看到一堆难以理解的内部映射
3.应急方案 如果Windows加载器的API Set解析机制出现问题，这些物理文件可以作为后备方案。
这些文件能独立工作吗？
答案是：不能。
就像你在问题中提到的，不支持API Set的加载器想通过这些文件实现转发是不可能的，因为：这些DLL本身并不包含实际的函数实现，它们的存在更像是一个"占位符"，所以真正的转发规则是由Windows加载器内部的Schema决定的
如果你用PE工具查看这些dll，你会发现它们都是极小的stub文件，基本上只包含导出表和最基本的PE结构。就像一个空房子，只有门牌号，里面什么都没有。真正的"家具"（函数实现）都在其他DLL中。
为什么微软要这样设计？
这个设计其实非常巧妙：不同Windows版本可以轻松改变API的实现位置；加载器直接处理重定向，避免了额外的DLL加载，因此性能方面也能有不小的提升；而且更容易管理不同版本的Windows API。
总归来讲，API Set是Windows系统一个精巧的设计，那些看似"无用"的物理DLL文件实际上是一个优雅的后备方案。
"有时候看似多余的东西，恰恰体现了系统设计的远见。"
对Windows底层感兴趣的同学请点赞关注，我是旷野，探索无尽技术！