Well, first of all excuse me if this request sounds bs/far-fetched for you. I'm not much familiar with MC modding so i dont know really if this would be viable to implement.

Basically, i'm currently still on 1.12.2 due to the dependency of TrainCarts by @bergerkiller on my modpack. It's a (fabulous) Bukkit plugin that basically makes minecarts useful. Btw, i'm "stuck" on 1.12 because both it's the last usable Forge version for me (performance-wise) and there is no hybrid servers that implement the Bukkit API over Fabric, except Cardboard. But, unfortunately, Cardboard simply doesn't support all the stuff needed to run BKCommonLib on it, and seems like it never will add such support.

So i thought if, Architetury could "translate" Bukkit/Spigot API as well, that would ease Berger's work in porting TC to Forge and Fabric. That would be a huge thing for interoperability of multiple platforms, and maybe not only TrainCarts but also other plugins currently locked behind Spigot could be usable in Fabric/Forge modloaders without any kind of compatibility layer except, of course, Architetury.

Personally, I'm not the biggest fan of triphora's response, especially the last sentence there.

The API isn't the best, yes, but it also isn't "held together with duct tabe and dreams" either. It has seen several improvements over the years and while the main project Spigot may not have the best API implementations do forks like Paper or Purpur try to fix that with additional API (that devs request for years now from Spigot), or by fixing existing API to make it more consistent and user-friendly.

Tho, I have to say that Hybrid servers should die already.
The Bukkit API (And by extension Spigot, Paper, etc.) are fundamentally different than Forge and Fabric.
While Forge and Fabric do have their own differences to each other are they still a lot more close to each other when comparing them to Bukkit.
Bukkit has a relatively rigit API that doesn't really allow modification of internal code without breaking other plugins, as the API itself is more or less an interface mapping methods to whatever internal methods are used. So if now a mod comes and alters the internals (i.e. by implementing their own methods), these links will no longer be consistent and break.

BkCommonLib works because berger specifically implemented fixes to try and support these hybrids, but other plugins using NMS, or even normal Bukkit API code may not work reliably anymore.
Just look at the Material API for example. It's a rigit enum and hybrids like Mohist break it 6 ways to hell to squeeze in custom items and blocks from mods, which breaks any plugin utilizing it.

So, conclusion: While I dislike triphora's response, do I agree that Architectury shouldn't add Bukkit, Spigot, ... support, as mods and Plugins should stay separate to each other and not become a mess.

Yes, Bukkit and its descendants are far too different from "direct" modding using Fabric/Forge/Quilt-like toolchains for us to support.

Architectury API itself is based on directly accessing Minecraft's source code, which directly goes against the design of the server-side modding APIs to my knowledge.

The build tools have really different requirements as well, so it doesn't make sense to reimplement them like we did for Forge, considering you'd still have to make the Minecraft-targetted part of the mod code completely different.

Personally, I'm not the biggest fan of triphora's response, especially the last sentence there.

The API isn't the best, yes, but it also isn't "held together with duct tabe and dreams" either. It has seen several improvements over the years and while the main project Spigot may not have the best API implementations do forks like Paper or Purpur try to fix that with additional API (that devs request for years now from Spigot), or by fixing existing API to make it more consistent and user-friendly.

Tho, I have to say that Hybrid servers should die already. The Bukkit API (And by extension Spigot, Paper, etc.) are fundamentally different than Forge and Fabric. While Forge and Fabric do have their own differences to each other are they still a lot more close to each other when comparing them to Bukkit. Bukkit has a relatively rigit API that doesn't really allow modification of internal code without breaking other plugins, as the API itself is more or less an interface mapping methods to whatever internal methods are used. So if now a mod comes and alters the internals (i.e. by implementing their own methods), these links will no longer be consistent and break.

BkCommonLib works because berger specifically implemented fixes to try and support these hybrids, but other plugins using NMS, or even normal Bukkit API code may not work reliably anymore. Just look at the Material API for example. It's a rigit enum and hybrids like Mohist break it 6 ways to hell to squeeze in custom items and blocks from mods, which breaks any plugin utilizing it.

So, conclusion: While I dislike triphora's response, do I agree that Architectury shouldn't add Bukkit, Spigot, ... support, as mods and Plugins should stay separate to each other and not become a mess.

I believe she was talking about the implementation being held together with "duct tape and dreams". PaperMC does admittedly improve on things though.

Forge isn't perfect and has some of the same issues! But at least it has a lot in common.

Nope, this definitely isn't going to be happening. I'm not one of the people in charge of the project, but I can still say with confidence that this is not happening. The only reason that both Fabric and Forge can be supported is because they are actually similar in a lot more ways than they are different. The Arch API shim can be used to have code that works on both because they are fundamentally affecting the same codebase (Minecraft). Meanwhile bukkit/spigot/whatever are touching a weird amalgamation of patched nms code that is held together with duct tape and dreams. Therefore, I'm sorry, but no.