Well, Moving Platforms is coming along with some degree of success. I didnt have too much of a choice but to make it dependent on Modular Passable tho. Its probably gonna take some time in order to maintain compatability with other scripts. I dont think I'll be able to do partial steps tho because it would decrease compatability severely, but is possible. I tried to leave the stuff to be as open and as compatabile as I possibly could. The SDK sucks. We all know this. But one thing that the SDK never did was to allow any changes to the definitions of Passable. Thats what gave birth to the idea of Modular Passable. Modular Passable is basically like the SDK but only for two very important methods in our scripts. And I've written quite a few scripts that enhance the movements of characters that all work together. It allowed for Stairs and Downhill Ice to work together, as well as Looping Maps, a Collision Optimizer (performance), Vehicles, Mirror Movement, Hotfoot Tiles, NPCs on Event Tiles, and a couple more that Im now working on, which will include Moving Platforms! So yes, you can have Stairs and Moving Platforms, or just Stairs or just Moving Platforms, but for them to work together, they need Modular Passable. Modular Passable by itself doesnt do anything. Putting the script in your game and you wont notice any other changes. Modular Passable is a framework that allows other scripts to alter behaviors with compatability.
I do recall having read your request for Z-Index stuff. I was able to achieve something similar to your requested effects with some clever eventing. Z-index stuff, like having different enemies on different layers, thats a small part of what I already did in the Modular Passable packages, and I did specific Z-Index stuff in several scripts. The caterpillar has some Z-Index controls, but also so does NPCs on Event Tiles and Restrict Tile Passages. The whole point of all the Modular Passable scripts was to give everyone as much control over everything as I could incorporate.
But I did do a bit more thinking about what you were saying. What I came up with seemed to work okay. It can be achieved with both Event Tiles by swapping Event Pages, and can be achieved by getting direct access to the tiles themselves. Events is way easier, but limited in scope, but swapping tiles creates an Illusion. If you duplicate a set of graphics in your tilesets, you can give them different passages and priorities, even though they look exactly the same to the Player. So what Im thinking is you have a map with at least two "Levels", a top and a bottom. While on the bottom, a player can walk under or behind some of the terrain, but on the top layer, those passages are totally different and allow walking around on all parts of the top layer.
Im pretty sure I understand givng a tile two sets of graphics, but that gets two deep into the graphics class to be able to do. However, there is another way to do it. Keep the graphic the same and give each Character a different set of responses to that same graphic. That is exactly what my Restrict Tile Passages script does. It doesnt just block, but allows movements also. So you can have one NPC walk on water, while another character is not allowed to move on water. You dont even have to change the passages in the database, so it is very character specific. Every event can be customized! You can set Wildlife to only move on Grass Tiles (with those tile IDs in an Array), or a Human NPC to only move on Road Tiles, but not grass! Being able to customize which characters (both Player and Events) is what allowed me to create a Vehicles script that allows the Player to move on Water or Lava, while NPC characters that move around at random wont be able to step on water or lava. So we dont need to do anything to the graphics, just monkey with each character. I tried to set this up to be as easy as I could make it. In the top ten lines of list of event commands, just put in one of three comments with an array of Tile IDs. \tile_allow_move[1] would allow an Event to move on a Water Tile if your first Autotile is water and normally unpassable. \tile_only_move[1] would be appropriate for a fish in water. \tile_no_move[252] might keep an Event from randomly stepping on a specific plant, if that is what tile 252 is.
I did do even more tho. Events can be both NPCs and Tiles. By default, NPCs can not step onto other Events, but with my scripts they can! So you can have a Bridge Event Tile and have an NPC walk on it! That one is pretty simple: \allow_npc Comment on the Event Tile. Its configurable so you can auto-allow NPCs to step on Event Tiles. The scripts also work together so the NPC will step on Event Tiles unless the NPC has a Comment of \tile_no_move[567] and the Event Tile has a Tile ID of 567. They'll step on everything else. You can even set Events to move through other Events, but still be restricted by Tiles! I called that \event_through So an Event with a Butterfly graphic can fly through other characters, even the player, but cant fly through mountain walls or big trees. All these things can be applied to the Player as well, but need to be done with script calls. For example $game_player.tile_no_move = [567,568,569] or in a Move Route Script @tile_no_move = [3,4,6,7,9]; @tile_allow_move = [1]; It gives you as much control as I could give you.
Im not sure I understand "Negative" trigger, but you seem to be familiar enough with scripts and programming in general that I think this explanation will be worth while. Triggers for each event can be changed with simple Move Routes! Even though you set the Trigger with the Editor where it says "Action, Player Touch, Event Touch, Autorun and Parallel", its a simple numeric value and that value can be changed as easily as Through can be turned on and off with Move Routes also. It just requires a script call: @trigger = 0 thru 4. The default of 0 thru 4 represent each of the default behaviors, where 0 = Action Button, 1 = Player Touch, etc. The default code says anything higher than 2 is an autorun or parallel and is always updated in its list of event actions, but you can go negative also! For example @trigger = -1 makes an event Untriggerable!
Anyway, almost everything I talked about has been done in the demo except for the stuff I havent worked in yet. Many solutions are already in place for you, but require some creative thinking. This script demo will probably take you HOURS to check out every feature because there are literally that many things I've done. It is a massive training session, and EVERY script is nearly fully explained and given fully functional examples! The things that I havent put in yet, I am now working on, and have numerous ideas.
Its almost sad when my Script Demo is bigger and more in depth than many games, and yes, there is even a part that lets you experience some actual gameplay with a Boss and everything! An actual Boss Battle in a Demo? Who'd have thunk it?