如果 MDX + MDD 合并成一个文件：
- 可以避免 MDD 丢失或者版本不匹配的情况。
- 资源引用稳定，用户体验更好，词典作者可以根据打包情况，调整页面的样式，比如没有发音资源，可以直接隐藏单词和例句的发音，避免误导用户。
- 方便词典文件的下载、分发和完整性检查，对于大多数词典来说，样式和图片完全可以和 MDX 打包在一个文件里，一个只有几 KB 的 MDD 文件也很奇怪。
- 词典软件实现也简单，不需要管理多个 MDD 文件，尤其是支持跨平台的时候。
- 一本书必须是完整的，不依赖外部文件。
我认为分开是有好处的。
如果MDX + MDD 合并成一个文件，对于那些多媒体文件很多的大型词典，解包/打包？也就是导出txt,生成mdx会非常麻烦。合并成一个文件应该是可以做到的，有你所说的好处，但也有很不方便的地方，所以没这么做。
我认为这个好处一般般。合并成一个文件优点太多了，如果你只想导出文本或者只想导出资源类似 mdict-utils 这种工具都很好处理。
论坛里到处都是图片怎么不显示，发音怎么有问题的回复。合并成一个文件这些问题就全没了。
你想象一下，一个词典的mdx有20M，mdd有2个G。如果合并成一个文件后想修改里面的文本数据，那么每次打包都要生成一个2个G的文件。如果分开，每次修改就只需操作20M或几百M的文件。
不过也可以提供一个选项，让人自由选择合不合并
文件格式设计麻烦，那内部就要弄成一个文件树。主要文本和附属文件的主要设计肯定有区别，两种混搭太混乱了，我不喜欢，分类比较好。
专门再提供发音版，平时修改用不发音的版本就好了。资源和文本分离有版本问题，你怎么知道你修改文本的时候，没有修改链接，或引入新的词条。如果合并成同一个文件，资源链接的完整性也可以由词典制作工具来检查。
主要是因为有的作者太喜欢分成多个mdd，以及给了太多的选择，让懒人头晕。我做词典肯定不会这么细致，一刀切省事。
还分发在不同链接里，看着就头痛。
mdx是键值对存储，mdd是类似文件系统的资源包，不同结构分开很合理，虽然文件系统也可以表示为键值对，但是分开明显节省了修改词典文件但不改资源的打包时间。其实我觉得mdd本身就是多余的，应该直接用通用格式zip之类的。
mdx的问题是没有统一metadata，如果要求词典指定语言就方便很多，词典软件可以根据语言信息来自动处理词条，还有没有保留词条原始顺序。
要我设计格式肯定和docx差不多，一个改名的zip里面放xml和其他资源。
ZIP 解压指定文件默认是线性扫描 O(n)，有些库提供了选项可以在打开时构建 HashMap O(1)，比如 LIBZIP，但如果资源文件特别多的话，这两种方式都不太适合。
同意保留词条的原始顺序，但可以猜测当时作者的考虑，重新排序可以确保词条的内容存储在同一个或者连续的数据块里，读起来速度更快。
我还认为词条的内容应该类似资源文件一样，要有自己的文件名，这样导航精确跳转都很方便。
文件合并和分开各有自己的优势，说不上哪个好哪个不好，反正我不喜欢下载和保存超大语音包。mdx如果和css之类的合并也许更好，可惜后者放到了mdd里。其实上面都是一些不痛不痒的问题，mdict最大的败笔在于索引机制，就不多说了，也许作者确实没学过除英语外的任何一门外语。
这么设计应该是考虑到当年的网速吧。
而且按照以前热门MDX/MDD的更新速度，如果合二为一，对于上传下载都是负担。
不过，最近了解了JSON格式的优点和在当下的广泛应用，我觉得把主要词典的MDX进行JSON化倒也挺好的，但innerHTML恐怕难以处理那些复杂的CSS样式内容。
zip有文件目录数据的，保存在文件末尾，不需要线性查找。
合并估计查词效率会降低，也不便于维护吧。面向用户来说我觉得主要的是mdd资源对于部分人而言可以为了节约设备存储空间而舍弃。
我说的线性查找就是你说的这个保存在 ZIP 文件末尾的中央目录（文件列表），除非你完整读取这个目录再另外处理。
节约空间可以出两个版本，发音版和无发音版，这样样式也方便处理。论坛很多对照的图片词典也可以这样处理，大多数人用不上图片版。
我认为需要 JSON 化，但不同词典的结构差异非常大，觉得希望渺茫。只支持少量常用词典或许可以做到。
其实所谓合并，也就类似于zip的打包，将mdx、mddd放在一个文件夹中，打包成一个zip，不就是一个文件吗。只是需要词典程序直接读zip文件即可，这个应该不难做到，以前很多软件都可以直接读zip。