先说一句：你可能认为这个问题最好在 LaTeX3 邮件列表中提出，但我相信大家可能对包加载顺序的拜占庭规则更感兴趣。我仅提到 LaTeX3，因为这可能是解决这个问题最明显的机会。
这是一个有效的 MWE；交换标记的行会导致其失败（选项冲突）：
\documentclass[draft]{memoir}
\usepackage[final]{graphicx} % <== Swap this one
\usepackage{fontspec} % <== with this to break it
\usepackage[final]{microtype}
% =================================================
\begin{document}
% =================================================
\mainmatter
For that reason among others,
typography and typographers must honour
the variety and complexity of human language,
thought and identity, instead of
homogenizing or hiding it.
% =================================================
\end{document}
显然，某处fontspec正在加载 graphicx（虽然我找不到在哪里）。
虽然我我很高兴能忍受这种小烦恼，我发现对加载包的顺序的限制可能是阻碍潜在 TeX 采用者的因素之一。
LaTeX3 团队对此有何看法？例如，在使用RequirePackage而不是时，是否可以抑制选项冲突检查usepackage，或者为包编写者提供通用的抑制方法？
或者这是需要是在每个包编写者的详细审查下？
答案1
总的来说，我认为默认抑制选项冲突是没有意义的——至少在它们表示不兼容的请求时是没有意义。如果一个加载请求表示像“X”一样行为，而下一个加载请求表示像“Y”一样行为，并且这两个行为不兼容，那么就需要解决这个问题。即使它们是兼容的（即可以一起使用），如果您尝试两次加载包，通常也不会起作用，原因有很多，其中一个原因是 2e 不是为两次加载内容而构建的（例如，\newcommand问题），而且现在有解决“X”和“Y”之间依赖关系的概念，除非包知道您想要同时使用这两个选项，否则这些概念是无法解决的。
我们可能没有完全正确理解 2e，并且系统在谨慎方面不必要地犯错也是事实。
基本上，在 2e 中，我们只是使用一种简单的方法来检测选项冲突，即测试新的加载请求是否不需要“额外”选项（如果我没记错的话，没有选中）。因此，请求较少的选项是可行的，因为假设这样做是可以的（这不一定在所有情况下都是正确的）。这就是为什么错误消息表明全局加载选项可能有效，或者更改包的顺序通常有效。
因此，我认为还有改进的空间，但它需要一个更好的模型来描述选项之间如何真正相互作用（这在 2e 中是不可用的，因此只有一组简单的假设）。
所以说到 LaTeX3 应该如何做到这一点：是的，它应该带有一个包加载机制，以改进 2e 概念（这反过来又改善了 2.09 的情况），但这一级别的设计尚未完成，所以这真的是我个人的随意之举。但有一点要补充我对 LaTeX3 帮助的回答因为它是一个需要思考概念上真正想要和必要的东西的概念。
但回到上面问题中的例子：expl3当前加载graphics并color在某些情况下，因此使用的 2e 包expl3具有令人惊讶的依赖关系，而这并不是应该有的。在我看来，我们需要在今后消除这种依赖关系。
答案2
只要顶层 LaTeX3 代码尚未编写，我相信它将改善“包裹订购自由”、“言论自由”，并使世界走向和平与和谐。
回答您关于 LaTeX2e 的暗示评论（这个答案的要点：）
例如，是否有可能抑制选项冲突检查
即使在 latex2e 中，也很容易抑制检查（您只需要重新定义\@onefilewithoptions不带检查的内部宏）。
问题是，如果您不检查，事情就会出错。如果一个包已在（比如说）pdftex 中加载，那么内部会为该平台定义其所有后端代码，然后另一个包尝试在 xetex（或 dvips 或任何模式）中加载它。那么已经加载的代码将无法用于新调用。如果您通过使用新选项重新加载包来覆盖所有定义，那么任何期望第一个版本的使用都将失败，并且无论如何，加载包（如果已启用）两次通常会失败，尤其是因为如果您\newcommand两次执行相同的操作，第二次会产生错误。
这些问题都不是难以解决的，但可能不是用当前的语法，因为除非你说出你的意思，否则抑制警告并没有真正的帮助。想给定输入发生
\usepackagep[dvips]{graphics}
\usepackage[pdftex]{graphics}
正如 Frank 在另一个回答中指出的那样，人们可以设想基本的 LaTeX3 功能针对不同的上下文具有不同的顶级接口。但是（我怀疑）对于接近 LaTeX2e 语法的接口，其中一些限制仍将存在，就好像语法允许人们搬起石头砸自己的脚（或砸别人的脚），你必须采取保护措施来防止这种情况发生。
答案3
David 和 Frank 都对此提出了很好的看法，但我认为有几点值得涉及，包括 LaTeX3 的可能性以及和expl3的当前使用情况。colorgraphicx
关于“原生” LaTeX3 机制的可能性，我认为我们会进行技术和概念上的改变。Frank 概述了一些需要考虑的一般领域，但值得记住的是，可能导致特定问题的领域是使用 keyval 选项，这些选项不是 LaTeX2e 内核设计的一部分，但已被使用。可以肯定的是，这些将由 LaTeX3 内核原生支持，因此类似
\usepackage[draft]{foo}
和
\usepackage[draft=true]{foo}
将被识别为相同。（在 LaTeX2e 中尝试此操作，您会发现它失败了，因为比较了整个文本。）
在概念层面上，LaTeX2e 中至少存在一些加载顺序/选项问题，这是由于软件包修补其他软件包中的命令的方式以及用户命令与实现的关联方式造成的。在这方面，LaTeX3 内核代码肯定会运行得更好，同时我们也鼓励其他人采用相同的方法。
最后，LaTeX3 的“计划”是针对比 LaTeX2e 更丰富的内核。这意味着当前从软件包加载的很多内容将位于内核本身或受支持的软件包中（目前还不是 100% 清楚！）。因此，许多当前的“高风险”领域应该得到解决。
在（当前）加载color和graphicxexpl3这最终与驱动程序有关，并确保东西正常工作。为了支持框变换（缩放、旋转、ETC.) 您需要驱动程序级别的支持，该支持由 提供graphicx。加载color包稍微复杂一些，因为加载它的原因与“颜色安全”框有关，以及它们如何与l3galley（ 的一部分l3experimental）中的厨房概念进行交互。
现在，这两个问题可以而且应该用其他方式解决。现在有可用于 LaTeX3 的“本机”驱动程序，它们支持旋转等，而无需加载graphicx。这里的限制是，目前这些仅支持pdfmode（pdfTeX >1.40 或 PDF 模式下的 LuaTeX）、dvips（pdfTeX >1.40 或 DVI 模式下的 LuaTeX）和xdvipdfmx（即 XeTeX）。当然，只有当您尝试使用依赖于驱动程序的部分时，才会显示这种有限范围的后端。对于color事情的方面，可以完全跳过加载，因为只有当人们尝试使用 LaTeX2e 用户级框时，问题才会出现l3galley（我想：自从我测试这个已经有一段时间了）。
这里最大的问题其实是有些人可能依赖我们加载代码。我们放弃时遇到了问题calc（出于好的理由），因为其他一些软件包是在假设可用的情况下编码的。
在撰写本文时，我们正在对其进行一些其他重要更改expl3，因此这是解决该领域的好时机：我认为是针对 LaTeX-L 的更改。