I don't think you should seek for some magic as there isn't any! Everything and anything can be programmed given some thought.
With Uzebox the tricky part is that there is little RAM, however on the other hand it has lots of CPU power compared to the old 8 bitters which ran the games we often try to mimic. This allows for less tricky programming (and of course using C instead of assembler) to achieve comparable results.
Some techniques I used in Flight of a Dragon related to your concerns:
Triggers:
FoaD has no triggers, however it has a few game elements which could look like using something alike. The maps encode enemies and objects (up to 256) on them, as you move around, always those activate which are within an enhanced viewport, a 384x384 pixels region around the dragon. When the game detects that an object is reached by the viewport (as the dragon is moving around), it activates the object if there is still room in the active object pool (12 objects). Then the object can be interacted or is acting on its own (such as an archer running around and shooting) as long as it is within the viewport. If the object is killed or consumed, then it is marked (256 bits), so it won't appear any more, otherwise even if it is removed (since the dragon moves away), later it will reappear.
This logic doesn't include projectiles which are processed by different components, distinct for the enemy projectiles (up to 8) and the dragon's fireballs (up to 12).
It neither covers torches which are special tiles, interacting by collision detection within the component processing fireballs. When alight they are user RAM tiles. Bridges which can be destroyed by bombs and doors which can be burnt down are identical to this. Both use the same underlaying logic: when the action is triggered (in the fireball code for the torches, in the bomb object's code for the bombs), they replace the 4x4 map block to one containing the alight torch or removed bridge / door, and again a flag is set indicating that the 4x4 map block is replaced (so it will stay that way until the end of the level). These flags take 2048 bits (a map can have at most 2048 4x4 blocks).
How do question blocks work:
There is something possibly similar in FoaD to how they might work. The doors are realized by a combination of sprites (so you can set them ablaze) and the 4x4 map block related code above. The sprite object is responsible for the capability to be animated (door is burning), and to allow it having a health (how many fireballs you have to pump in it before it falls). You can imagine that if I reused the FoaD code to create some Mario game, I could implement a question block in a similar manner.
How do power-ups work:
Power-ups in a single player game is simple: your player is a singleton, so you can store the player's status with ease, without the need to consider multiple objects. Your concerns mostly are rather gameplay related than coding (what power-ups, can you lose them), you have to design it by the impact you want them to have on the gameplay. In FoaD I fine-tuned them for several months when I already had the game playing well, mostly concerning three aspects:
- What the power-up does (in FoaD: Increase firepower, Increase energy, Increase life, all also improve recharge rate)
- How difficult is to get the power-up
- What the power-up's impact is to later gameplay
To have an useful power-up system enriching the game, these have to be balanced. As far as I see, in FoaD you might be able to push farther without getting a particular power-up if you are pressed, however that may doom you later. But you see a further section of the game which might motivate you to try, and if you successfully get the power-up, progressing should get noticeably easier.
Recoloring or replacing the sprite is a coding matter. In FoaD this is possible as Mode74's integral part is a capability to recolor sprites, and such a capability is useful as it is cheaper in ROM space than a new set of sprites (especially if they are richly animated). In this game damage recolors the dragon (flashing him red when he receives some).
How does shooting work:
Dragon fireballs (up to 12) and enemy projectiles (up to 8) are processed by different components, however their physics is shared with each other and any other object moving around on the map.
The physics engine of FoaD is pixel by pixel, every movement is carried out in pixel by pixel steps. This is CPU costly (and here the AVR shines), however it produces a fairly good result, making weird object-map interaction bugs less likely, at the very least eliminating the possibility of most game breaking ones (like getting stuck in the map or passing or falling through a wall or floor).
It is possible to have at most 12 objects (enemies, power-ups etc., excluding the dragon), 12 dragon fireballs and 8 enemy projectiles active. The separation ensures that neither can "starve", which could be game breaking: it can't really occur that someone can't shoot because a lack of room in a necessary object pool.
How do boss battles work:
Foad has no such, however one nice idea was already executed in Tank Fu: there the final boss is background tile based, and it looks quite impressive. You could check the code of that, although just by looking at it carefully can reveal how it is done.
Having a large boss in a normal (no SPI RAM) Uzebox game might be just too costly, so I think one should consider having or not having one very early in the design. It will take away lots of ROM for graphics and code which is only used within that boss battle, which could be used to enrich the game elsewhere. If you have SPI RAM, you might be able to add a boss without too big ROM cost (Mode 74 and Mode 748 can source sprites from SPI RAM which could be very useful to reduce the ROM demand for graphics).
Links to game Wiki pages:
Flight of a Dragon
Tank Fu