If your uname output, compiler architecture ifdefs, etc, don't match the existing architecture then basically every program that does per architecture specialisation will need updating, even if fairly trivially so.

If you're not building and running identical binaries, then anybody who distributes binaries needs to be persuaded that it's worthwhile to get hold of build machines and devote archive space and maintenance time to your new architecture.

There may be political issues where neither the owners of the old architecture nor the owners of the new clone want to come out and admit that it's very similar. This may result in projects treating it as "genuinely new architecture" rather than "variant of an existing one", which is more work. (There are also technical concerns about future divergence that might argue for "not just a variant".)

If you have to have the code structure of a complete new architecture then this can also trigger more work where the old arch code got to get away with legacy practices and APIs but the newcomer is expected to reach any project standards for new code, so "copy, paste, rename" is insufficient. Sometimes this imposes constraints that make more work elsewhere: for instance a new architecture in Linux is expected to follow a modern syscall numbering scheme and set of syscalls, so it won't have a userspace ABI that's compatible with the arch it is cloning.

If the architecture you're cloning is a "declining" architecture now mostly in legacy setups, then modern projects you care about for your new architecture might not have good or any support for it. (If you cloned sh4 you won't have easy rust support, for example.)

Overall, getting a new architecture from "we have a spec" to comprehensive open source ecosystem support is a heavy lift, and clone and copy doesn't get you out of all of it. (Look back at how long it took 32 bit Arm and then 64 bit Arm and now how riscv is following similar paths. These have all been years long efforts with a very long tail.)