The expected instructions for inline functions by the Kotlin compiler

Hello, a little backstory of what we are trying to do and what causes issues compiler issues for us.
We mainly deal with Android AAR (Library) files written in Kotlin and we want to have conversion of the jar files into the native dex files, and afterwards integrate it back into the jar files so that the library could be used as normal.
The issue we are facing is that for Kotlin inline functions the compiler seems to be very sensitive on the ordering of instructions and some expected instruction patterns, while using something like jadx to observe the desuggared code in java it would look the same, some of the bytecode instructions use different registers or have a different ordering.

So what we are wondering is there an expected list of instructions/registers for the compiler to pick up those inline instructions properly.

As an example (we can provide many as needed, but this is a simple case so probably easier to understand the issue):

Because right now after the process and trying to integrate the library into an application we are getting a compile time error at the likes of:

org.jetbrains.kotlin.backend.common.BackendException: Backend Internal error: Exception during IR lowering
...
Caused by: java.lang.AssertionError: 'checkNotNullParameter' should be invoked on local var, but org.jetbrains.org.objectweb.asm.tree.LdcInsnNode@4eb4f67d

which happens already after performing conversions on the following simple method:

inline fun <reified T : FragmentActivity> getParent(type: Any): T? {
    val converted = type as T?
    return converted
}

And looking at a simple inline instruction bytecode here on jadx, before the mentioned conversion cycle it looks like this:

.method public static final synthetic getParent(Ljava/lang/Object;)Landroidx/fragment/app/FragmentActivity;
    .signature <T:Landroidx/fragment/app/FragmentActivity;>(Ljava/lang/Object;)TT;
    .max stack 3
    .max locals 3

    .local 0 "type" Ljava/lang/Object;
    aload 0
    ldc "type"
    invokestatic kotlin/jvm/internal/Intrinsics checkNotNullParameter (Ljava/lang/Object;Ljava/lang/String;)V
    iconst_0
    istore 1
    .local 1 "$i$f$getParent" I
    .line 8
    aload 0
    iconst_1
    ldc "T?"
    invokestatic kotlin/jvm/internal/Intrinsics reifiedOperationMarker (ILjava/lang/String;)V
    checkcast androidx/fragment/app/FragmentActivity
    astore 2
    .local 2 "converted" Landroidx/fragment/app/FragmentActivity;
    .line 9
    aload 2
    areturn
.end method

and afterwards it changes to something like this:

.method public static final synthetic getParent(Ljava/lang/Object;)Landroidx/fragment/app/FragmentActivity;
    .signature <T:Landroidx/fragment/app/FragmentActivity;>(Ljava/lang/Object;)TT;
    .max stack 3
    .max locals 1

    aload 0
    dup
    ldc "type"
    invokestatic kotlin/jvm/internal/Intrinsics checkNotNullParameter (Ljava/lang/Object;Ljava/lang/String;)V
    iconst_1
    ldc "T?"
    invokestatic kotlin/jvm/internal/Intrinsics reifiedOperationMarker (ILjava/lang/String;)V
    checkcast androidx/fragment/app/FragmentActivity
    areturn
.end method

Which based on the instructions themselves being executed, the ordering seems to be different, and the original code has some additional instructions that seem to be important in this case, but I do not understand why, as the code should do the exact same thing based on what is being executed, but the additional loading and storing of registers seems to have some effect on it.

We have tried circumventing some of these more basic cases, by adding and moving instructions in a hack-ish way to match what is observed, but the more complex usage the more edge cases we could encounter here, so it would be nice to known how to do this the proper way.

Additionally, we are interested if there is a set pattern that should always occur in order for the Kotlin compiler to properly pick them up, can we expect that pattern to not change or is that something we should be rechecking for each version of Kotlin?