My other hack was SMW 1.5, I cancelled it for multiple reasons. It had horrible level design, I started it without any plan whatsoever, The overworld sucked horribly because I used the old SMW paths moved around, and my computer randomly deleted a lot of files, including that one, so I lost it.
It's multiple custom blocks. On spin jump, the top block changes itself into 25 and the block below it is also changed into certain other blocks based on what it (the block below) is at the time. The block that's for a one-tile high post just changes into the next block in the map16 on a spin jump.
I made them myself. They are custom blocks, but I also inserted a modified version of dhblock.bin from blocktool (the one used for changing blocks into the next map16) into the ROM so I wouldn't have to disassemble the code and have to use reloc addresses in my code. I may release them shortly after I release the first demo, but I'm not ready to release them yet.
When (or if) you do implement pseudo-multi-layer scrolling, I think your default RAM address for the HDMA table should be something like $7EC100, where there is enough space to fit all scan-lines into individual entries. If you use the same type of HDMA table as BMF's HDMA engine, this would be 673 bytes (or $2A1 bytes hex) that need to be free. The kind of background that would need this would be something like DKC Coral Capers (which uses almost that amount of differently scrolling scan-lines, with the exception of the blue part in the middle)
I shrunk BG1's tilemap to 256x256 and moved it to take up the last 4 rows of sprite GFX. In it's original space, I put 2 extra GFX files. I don't even need a map16 page for the BG. This is all done by a custom block that executes on the first frame.