The fact that we now combine the fully qualified class name, the method name, and optionally argument into a single thing makes the RELEVANT_METHOD_NAMES parameter construction fragile.

I think we should move to using a real class here to reduce changes of mess ups / typos, etc

You mean something like this for the key?

data class SuspectMethod(
  val klass: Class,
  val method: ???,
  val arguments: List<Type>? = null,
)

I've been spinning on a proper solution for this for an hour now :|

Ideally, when we do checking, we can go from relevant method to required parameter types to isInstanceOf for the relevant class. That would be best perf wise.

So maybe we want to go with Map< Map< Tuple<method name, requiredParams>, classname, Replacement>

WDYT?

What about something like Map<String (method name), List<MethodDetails>> with

data class MethodDetails(
    val containingClass: String,
    val requiredParams: List<String>? = null,
    val replacement: Replacement
)

The implementation could look mostly like the previous one, with an additional line in the potentialReplacements.forEach which checked the parameters.

Does this message make sense, given that a different method with the same name is allowed? It seems like it would make sense to include the "()"

This could use expectClean().

There should be a space either before the closing " on this line or after the opening " on the next.

What about something like Map<String (method name), List<MethodDetails>> with

data class MethodDetails(
    val containingClass: String,
    val requiredParams: List<String>? = null,
    val replacement: Replacement
)

The implementation could look mostly like the previous one, with an additional line in the potentialReplacements.forEach which checked the parameters.

One thing I'm concerned about for the parameter type strings is how they would work with generics, e.g. if we had

interface Interface<T> {
    fun someMethod(t: T)
}
class StringClass: Interface<String> {
    override fun someMethod(t: String) = Unit
}

and wanted to ban Interface.someMethod(T). When this is used as StringClass.someMethod(String), then I don't think matching against the parameter strings would work, and might require looking at the super methods to fully support that case.