经过一段时间的尝试和错误（主要是错误🙂），我可以部分回答我的问题。
我试图避免使用编译器插件的路径，因为上面没有太多的材料。Kotlin的官方文档只提供了这类插件的示例--没有概述或至少是基本的概念性说明，各种第三方文章大多建议通过查看现有的编译器插件来指导自己。同时相应的API可能会发生变化，所以我决定推迟这种方式。
我的注意力集中在尝试为此扩展detekt上。以下是一些观察结果：
1.用于分析代码的访问者的范围被限制为单独的源代码KtFile。不确定是否可以引用一些detekt文档页面说明这一点，但可以从它的API中推断出来（也可以在相应的GitHub讨论中找到直接的答案）。
1.#1的结果是没有办法写出这样的规则：在访问了所有文件之后，没有用于规则实现进行某些处理的方法。如果我们对访问的每个文件进行必要的检查，我们将没有足够的信息来说明某个变量是否在整个代码库中使用。当然，也可以尝试做一些肮脏的变通方法--例如，通过使用静态集合来累积访问过的引用，并最终触发它们的整个验证，但它似乎并不稳定。
1.看起来可以编写一个自定义处理器，因为它在访问所有文件时触发回调。但在这种情况下，我们遇到了detekt允许为处理器报告的方式的限制-它只提供定量报告的手段。当然，我们也可以将我们想要报告的所有内容都包含在ProjectMetric::type字符串中，但我想总有一天它会受到限制。
1.没有办法对所有变量和各种其他引用使用类似依赖树的东西。代码分析更像是基于标记的字符串阅读。我尝试了一些基于FullQualifiedNameGuesser用法的启发式方法，但是在尝试查找某种用法的声明时，它不能提供稳定的结果。
1.即使上面的所有问题都可以通过一些变通方法解决，它也会有一个巨大的性能过剩，因为我们基本上收集了整个代码库中的所有声明和所有引用，并最终匹配它们。
总而言之：我认为通过可用的API扩展detekt并不能解决问题中描述的问题。我去检查别的东西。

更新（20.4.23）-尝试了Qodana，UnusedSymbol检查做了类似的事情（从相反的方面来说有点），但它不是很可扩展（通过代码手段），并且需要Docker运行。它也可以使用Structural Search和导出其模板来运行Qodana，但它似乎不是我所需要的。