I say this as probably one of the most skilled rm2k3 devs (credentials: rpgmaker.net/games/5794/), don't develop using this generation anymore.
I think this project is neat from a preservation perspective, but there are so many limitations to its target engine that you will quickly bump into if you try to make anything that even approaches the quality of a real SNES RPG.
You're much better off using one of the later gen engines that uses JavaScript (probably whatever the very latest is).
Looking at the timelines, kind of surprised you didn't cut your losses and use RPG Maker XP or later w/ ruby as the scripting language, which was released in 2004. I'm estimating that project wasn't started before 2005?
Why did you stick with using that when newer engines were around?
The project was started around 2008 iirc! XP and VX were out at the time, but the larger resolution and mapping limitations were dealbreakers for me. They've since fixed these issues in the more recent engines so I wouldn't choose that again.
When EasyRPG Editor will be ready (that's a big "when", of course), it will feature improvements over the original RM2k3.
Most likely this will include other graphics sizes (Ghabry had already made an experimental branch for that) and plugin support (again, there used to be an experimental branch using Ruby by make-cheese already).
In fact, EasyRPG already includes some improvements (Unicode support, modern image formats, etc.), but it's difficult to use them because there is no editor supporting them (well, unless you count R48, but it's not user-friendly).
The funny thing is that I implemented all the mechanics but burnt out on the pixel art, and I can't see myself wanting to grind that out. The game has 700+ scenes!
From a programming perspective, the scripting language is at about the level of assembly. Expressions like A*B+C*D have to be manually decomposed into add/multiply instructions with temp variables. To call a "subroutine", arguments are passed through global variables. Many of the inputs to the builtin commands have to be fixed constants, ie. you're very limited in where variables can appear.
The "pictures" you're allowed to use (sprites that aren't the map, objects or system UI), must be explicitly set so if you want to render an integer as a picture you need 10 if statements per digit to select the right image. This has been resolved in re-release on Steam/etc, and also originally could be worked around using Cherry's PicPointer patch (which my project would've been impossible without).
All these complaints actually sound like good things to me, actually.
The platform has a very specific goal and it does not attempt to offer you a half-assed way to reach outside of that goal.
Like, what you just described should be accepted as "sprites can't be used to display numbers, that is not a feature of this engine", not "doing X is really hard".
These complaints sound like complaining about the difficulty in making an FPS on the Pico-8, or drawings in Microsoft Word. That's not what it's designed for.
I know the web has gotten us used to the idea that any platform can be hammered into whatever purpose we like, and so a document engine is now the frontend of all applications, but there's something to be said for having a clear, refined, limited purpose.
I've never used this engine, but I used to make ums maps in StarCraft 1. The programming language there was glorified outlook Mail Rules. You had to plan your gameplay around the capabilities of the platform, not the other way around.
The result was a lot of fantastic games that still felt like StarCraft.
I think this project is neat from a preservation perspective, but there are so many limitations to its target engine that you will quickly bump into if you try to make anything that even approaches the quality of a real SNES RPG.
You're much better off using one of the later gen engines that uses JavaScript (probably whatever the very latest is).