在目前阶段，l3draw使用起来相当麻烦。 也一样pgf。由于两者都是背景层，我猜它们并不适合普通用户广泛使用。
是否有计划支持 TikZ 作为前端l3draw？
这对最终用户来说有很多好处，例如更好的数值精度。我不认为新的前端是个好主意，因为 TikZ 拥有庞大的用户群，并且有很多有用的库。
答案1
简短的回答：不。
这项工作的核心目标之一expl3是提供一种不依赖于 TeX 基元、内部 LaTeX 宏和文档程序员/设计者/文档命令（在“经典”LaTeX2e 包中可以看到）的混合的 LaTeX 编程方法。其中大部分内容是关于提供核心编程层，但扩展到需要基元支持的其他领域。
使用 PDF/PostScript/SVG/... 构造在最基本的层面上创建绘图是使用一个或多个基元：\special、\pdfliteral等。这些显然属于“TeX 基元”层。我们的l3draw目标是充分抽象，以便可以使用文档化的界面创建基本的绘图构造expl3。这项工作开始于团队仍在设想未来独立于 LaTeX2e 的 LaTeX 格式时，但现在这个目标已经不再适用，其核心思想仍然适用。
因此，l3draw可用于实现各种更高级别的接口：例如，可以相对轻松地制作出类似图片模式的东西。但是，对于任何类似 TikZ 的东西，都有几个重要的注意事项
- 虽然
l3fp相对于其实现的效果来说速度相对较快，但dim基于 - 的方法pgf更快，特别是在跳过解析并进行低级计算时：这对于全面的l3draw基于 - 的 TikZ 方法来说意义重大 - TikZ 接口对于 LaTeX 来说非常不标准：因此，团队的任何代码都不可能以与 TikZ 相同的方式工作
- 虽然
pgf和l3draw有类似的 API，但 中的维度计算l3draw是通过扩展完成的，而在 中pgf它们是不可扩展的，并设置（记录的）返回dim寄存器\pgf@x和\pgf@y。 TikZ 的实现不仅严格使用pgf记录的宏接口，还使用这些寄存器和其他低级代码。 因此，不能“插入”l3draw函数来替换pgf函数。 l3draw尚未涵盖 的所有pgf功能。有些领域有待 PDF 结构方面的工作成果（例如对掩码的支持）。还有一些pgf级别的想法，人们可能会认为它们不需要内核级别的直接expl3支持，最明显的是节点。
因此，l3draw最好将其视为程序包作者使用代码级接口在已使用 的程序包中构建功能的一种方式expl3。在某个阶段，我们可能会将l3draw其作为 的一部分加载l3kernel，但目前没有压力这样做。