This is the kind of mechanic that is probably non-obvious to think of if you're just brainstorming ideas, but arises naturally when you start implementing the physics. The spin move could be implemented by setting vertical speed to a certain value, which would give a consistent boost height, but instead I implemented it by adding a small value to the current vertical speed, which gives the effect you see in the game.
After playing this game, and reading this comment in the design notes, I started to feel like this is the key to understanding a certain important thing in many (or all?) of your games.
(Maybe this will all seem obvious, or maybe you covered it in a previous blog post that I didn't read, but it was a new understanding for me that was provoked by playing this game and I wanted to share it.)
Let's say a bit more than you do in the notes first. You say:
if you spin at the peak of your jump (vertical speed close to zero) or while falling, you get a small boost, but if you spin immediately after jumping (high upwards vertical speed) you get a huge boost
...but actually the way this is tutorialized in the game is as 'mermaid jump: up + w', in other words the easiest way to get the highest jump is just to press both the keybinds for 'up' at the same time, so you get the double boost on the same frame (or close enough).
I would find it hard to believe you decided to add WASD support along with the arrow keys as a way to implement a secret high-jump mechanic. I would assume instead that you implemented both keybinds for accessibility reasons (or maybe they were on by default in game maker) and you happened to notice that this was a good way to get the high jump. I could also believe you happened to notice that your additive jump implementation had this nice effect, or maybe you chose deliberately to implement the jump height additively rather than by setting velocity, doesn't really matter, what I'm more interested in is this W+Up thing which is clearly more in the style of 'noticed and liked and kept'.
This is not really the normal way to do mechanics. What's more orthodox is to dream up a solution to a game design problem, then go out of your way to eliminate edge cases and implement it as planned. By itself, this jump thing is not that big of a deal, there's probably a little bit of stuff like this in every game (one that springs to mind is how everything in Spelunky has health, so you can kill the 'invincible' ghost given enough of an explosion). But reflecting on your games such as Jiggly Zone, Sylvie Lime, Clockwork Calamity, I think this approach to mechanics - actually let's for now say 'mechanics' - is really a calling card of your work.
I'm can only guess about your process and intentions of course, but here is an example that I think follows the same course: in Sylvie Lime the save system is implemented as a 'house' object that I can throw. I can teleport back to the most recently thrown house, so it works as a checkpoint/save system in a normal way. But because I can throw it forward (like other objects I can get), it isn't just a way to rewind time, like a save system normally does; it lets me traverse forward in a safe way by 'restoring' to a place I have never been. Thus by choosing 'throw' as the way that places the checkpoint into the world, you allow a new, weird, original traversal 'mechanic' to exist. But more than just allowing it, you chose to build the whole game around this implication.
This seems like a unique characteristic of your work to me. And it's not as though these design moves are always a case of keeping the implementation simple and letting deep implications remain, as in Discover the World's jump. In Jiggly Zone, for example, it's more like you allow the level design to create new implications of a relatively simple set of game mechanics, and then follow through on that by making the level design more and more extreme. But in any case, the aesthetic is something like 'allowing effects to exist and helping them to flourish'.
After playing Discover the World, I started to wonder: are these effects really 'mechanics'? We teach people at game design school that games are made up of mechanics, and mechanics are rules that are invented by the game designer to control the flow of play. Of course it sometimes happens that a side-effect of the rules or maybe an unintended effect of the implementation will be enjoyable and will end up being kept. But couldn't someone try to make a project of creating whole games out of 'allowing effects to exist' instead of 'inventing rules to produce specific effects'? I think that would look a lot like your library of work.
I was trying to understand what you meant by "game design is a prison", or where you say it more clearly here:
I suddenly entered a sort of "hell" where I had to consider the results of my decisions. Well, I didn't have to, but it became hard to accept the results as they were
Of course reading something like this, one will wonder: "why is this a hell?", after all what you're describing is the thing that many game designers love to do the most. But if I think about your project as being to let things exist, then of course coming up with solutions to design problems is somehow opposite that, and your description of this as being unsatisfying makes perfect sense.
Lately I feel I'm growing weaker and more feeble
I have felt like this myself on more than one occasion. I won't try to offer any advice or words of encouragement, except to say I think what you've been trying to do (if I'm right) is incredibly hard and you've been succeeding at it, and it makes sense to me that when an artist succeeds in doing something they will naturally try to do a harder and harder version of that thing until it becomes literally impossible. So we all gravitate toward failure, or at least failure by our own lights.
tl;dr: big fan of your work!