Hey bro, sorry I've taken so long to reply. I'm going out of town tomorrow morning and figured you'd want the feedback.
By the way, you may know me under a different name. 
I don't check these boards much anymore and didn't know you were on here!
Nickslayer? Or maybe Chris (since there's no mentioning of stuff NOT in this demo)? I don't really give yoyogames forum as much attention as this one.
Well my real name is Chris, but I haven't been to the YoYoGames forum in ages. There I was known as
HelpTheWretched.
1) Dissappearing rupees etc. Excellent suggestion. They normally dissappear on there own (just wait a bit), but moving from room to room pauses that. I hadn't even considered that would happen, but I can fix it by not dissabling the items in the old room. This will let them dissappear in real time.
This solution would be unlike the real LTTP engine because then you could exit and reenter a room to find the items still there. But, if you ask me, that's an improvement. I mean, why not let the rupees have their due time to be picked up? I'm willing to bet that this particular "staple" of the Zelda series began as a technical limitation before it was accepted as a regular part of gameplay.
2) Respawning enemies/containers. Like the original game I work with separate area's containing multiple rooms. This will respawn enemies and containers when you move between gamemaker rooms. So when moving outside or to another floor. This will include ALL regular enemies. It doesn't have to be exactly like the original.
Right now the containers follow the same principle. If you'll remember pots respawn but the contents do not. I would be broken otherwise anyway (...)
The containers is a valid point. The only reason I'd consider having their contents respawn would be if the dungeon design
required you to break it a certain number of times to obtain X items, or if there would be some kind of puzzle that involves getting their contents in the correct order. In the case of the former, it would also be important to make it somehow puzzling to get back to the container in the first place. In other words, I'd keep it as-is unless you really want to go through that trouble to make something unique.
As I recall mentioning (though maybe I didn't), I hadn't studied how/when enemies respawn. I'd suggest respawning them after traveling to a certain number of other rooms, rather than just when changing Game Maker rooms, IF the dungeons are rather large. Walking around through large floors with all the enemies beaten could get boring. A thought just occurred: it would be neat to actually SEE them respawn via some magic power, rather than just being there when you walk in.
Also consider the overworld; most if not all enemies respawn when you change areas.
3) The transitions are done by taking links current location and a target location. The distance is divided by the number of frames it takes and link moves accordingly. If you got caught in between two doorways my first guess would be that I made a mistake setting the target location or accidentally moved a transition object. Was this a one time occurrence for that particular doorway? The distance should be about 2 pixels longer than it absolutely has to be. At what door did this happen?
With "target location" transitions, yes, extending the target just a bit might be the best fix, but he already seems to hit the target location a few pixels farther than expected, so it must be some other kind of bug. It was a one time occurrence for that door, but Link went back and forth a good 8 times or so before I freed him. It was the door between the room just after the 1st key, and the room to the left that's just a horizontal bridge with 3 pots.
If you're using division by frames to control Link's movement during the transition, then perhaps it was a perpetual rounding error. I'm not sure how your walking code works, but if it allows Link to be at a non-integer (x,y) position at any given time, then I'd suggest also rounding off his position before the transition begins.
This just in: I reenacted the bug by dashing at the upper part of the doorway so that Link passes through but still makes the collision noise. Took many tries but I made it work 3 times. Perhaps since Link is supposed to bounce back, the target position ends up getting pulled back a bit.
Also, where the 9 pots are just above that door, sometime in the midst of cutting them up and pressing D (I think) repeatedly to get infinite blue rupees out of one, Link's sword somehow got moved an entire 2 blocks to the left and 1 down. It stayed that way through every movement until quitting.
4) There were some bugs in the starting menu but I already fixed those shortly after I posted the demo.
Cool.
5) Cannonballs it is. I'm not changing the name in the game because that's more work than it's worth. So, error messages aside, it's now cannonballs.
They do rather look like cannonballs, don't they? Well implemented, too.
6) The spin attack already uses both sounds, just not very noticeable. I haven't played the game for a long time but I didn't really feel like it sounded right.
The two sounds are supposed to play simultaneously. If you've got an emulator, try disabling the first 6 sound channels to leave just those two. #8 is the one I mainly hear, and #7 is the one I can't. It's like a quieter version of the beam-shot from the sword.
7) The masking of pots is something I'll look into. I kinda like the walking around them. It shouldn't interfere with your ability to grab them, but I could be wrong. I'll make a note on my list.
The last responder suggested square object masks. I'd go for
almost square, perhaps 14x14 with very slightly rounded corners, since making them slightly easier to walk around is a nice touch. As long as it still feels like you're playing Zelda, why not improve the formula by a little bit? But getting stuck between them (which I didn't know about) and having trouble picking them up are significant problems.
. With Galaxy 2 the only new feature seems to be Yoshi. Ah well the future will tell if the games will be good.