Thanks for the in-depth response. I'll certainly have to keep this in mind with future game jams and if I work on this game post-jam. I did want to go over some of what you said and respond to it directly.
The first thing that comes to mind is definitely Rhythm Doctor's moving windows stage.
I actually haven't played Rhythm Doctor yet, but I did watch a video of that stage, and it's on my list of games to play. In retrospect, I think the idea for this game was largely inspired by Outcore: Desktop Adventure, but that's more reminiscent of desktop buddies and is more of an action-platformer than a puzzle-platformer. (I do very much recommend Outcore, though. It's a great and, shockingly, free game).
Transparency didn't work for me (Meaning black squares behind every PNG)
I did have a note about this on the game page, since a playtester did run into this issue, but we got the cause wrong, and I removed it when it was shown not to be the cause. I have since added a new note to the game page based on the information you provided (thanks). I included some workarounds, but I don't expect you to replay the game for that or anything.
Ended up doing a jump while moving the window to avoid the second obstacle, cheesing it. I thought that was the intended way of solving it - the box being a red herring.
Congratulations: you figured out the speedrunning route. I had thought of that about that when I made the level, but decided it was more interesting to leave it in for experienced player than to try and prevent it. I thought it was unlikely that anybody would think it's the intended solution, but clearly I shouldn't have made assumptions. Most of the other levels also have less obvious solutions that are slightly faster, which is partly why we included an in-game timer to try and encourage the kinds of people who would seek that sort of thing out.
The game introduces multiple mechanics in a single level...
Ok, the context of what happened here is that it was both a side-effect of the development process, and an attempt at something that maybe didn't convey very well.
What's important to keep in mind is that the levels were created in the order that they occur in the game. The first level was designed by me before I even started coding anything. The test I made of the concept was just the box falling out of the window. As I said in another comment, the idea was this was meant as an iteration of a basic puzzle structure that's in a number of puzzle games. The example that comes to mind for me is Portal 2, where there are a number of levels that require you to do something to lower a platform, stand on the platform, then use portals to do something to get the platform to rise.
The second level was one that I made (had to double-check my chat log to remember who designed that one) very quickly after making the first level. I also described it as a tutorial level, and hadn't entirely decided what I was going to do with it. More importantly, I kinda ran out of ideas with that one, and asked Mypetblackie to come up with some level concepts.
She ended up sending a few different level concepts, but a lot of her ideas involved adding even more game mechanics (eg. one suggestion involved canons you could launch yourself out of). I was quickly growing concerned about running out of time with the game jam. Implementing more objects with unique behaviors would take increasingly more development time (keep in mind that the game mechanic where things off-screen stop existing causes everything to become more complicated to implement), and I was worried we were headed in a direction where each level introduced its own mechanic that would take significant time to implement. I challenged Mypetblackie to design levels with the mechanics we already had. The result of that were levels 3 and 4, which notably didn't make use of a lot of the mechanics of the first level.
When considering the levels, and how I might have re-ordered them, I still don't think the first level would work in the game as anything other than the first level. I still see that first level as a subversion of expectations: the first level looks like a fairly traditional puzzle level until you figure out the twist, and then the subsequent levels build on the twist (level 2 adds multiple windows, level 3 adds falling down into a new area, and level 4 adds non-resizable windows). It's clear from the feedback that the first level has issues with conveying the twist, but I think moving it later into the level would have been worse. That "unintended solution" you found is much more obvious once you have a better grasp of the game mechanics. I think that was a big limitation in bringing those mechanics back in later levels; it's not really feasible to make puzzles around togglable walls when you can just jump over / around / through them. Perhaps ditching that first level I made and making a new introductory level would have been a good idea, but I only realize that in hindsight.
It could use work from a design perspective, but that's alright for a jam, as I do not expect a polished AAA quality game within 3 days. :)
When I first came up with the idea, I was uncertain about pursuing it. I didn't have experience designing puzzle games, and I was very much worried about coming up with enough interesting levels in the time limit. I do think it mostly worked out in the end, and I'm happy with what we made, but I also understand that my inexperience with the genre certainly had an effect on the end result.
Thank you again for your feedback.