Basically using TAS to input commands at such a rapid and calculated pace that it tricks the game into thinking that a programmer is writing it code, first by opening the 'programmer' prompt from the game, then when things start getting really glitchy is when he starts inputting code that actually makes up the game structure.

Well. I have one of two ideas.

Both of those ideas revolve around a special characteristic of how the game's sprite animations work.

To explain in better detail. Check out this explanation for a separate glitch
www.youtube.com/watch?v=vAHXK2wut_I

Now. You can either hardcode this game into making the two games by using its own engine. OR what I think happened is that they just hardcoded the game to using something hidden in the game

I think this is the video. They explain in this.

a programmer in real life?
so you program reality? that's pretty cool
can you fix the glitch where most meats taste like chicken? probably mixed up some pointers

I'm just used to saying "irl" on the internet

I'm afraid that's a hardware issue. Taste buds just aren't developed enough, so it defaults to chicken.
-also a real life programmer

skills lose experience over time if they're not used regularly, is this going to get patched?

No, that stays as a balancing factor. Humans are too over powered already.

too over-powered? we don't even have health potions and the mana system has been broken for centuries!

Tell that to the animals.

it's not the players fault that the programmers put in mundane creatures only

Well, there is a test version where everything else was buffed instead of nerfing people to help balance it out. It's being tested in Australia.

But then you still would need some sort of custom code inserted into the game that you then trigger with a stack overflow. I mean, the one where they switch it suddenly to super mario bros, those graphics wouldn't have even been present on super mario world. No amount of tapping "left right left x x left" is going to create new graphics and a new map layout. Idk I have to be missing something here.

It's all 1s and 0s. even the code that gets executed is just a series of 1s and 0s that is stored somewhere on the machine.

When you perform certain actions (such as yoshi eating something), some memory gets changed to represent what object is being stored. Then when yoshi spits the entity out another piece of code gets executed. Using inputs at exact times, you can get yoshi to eat entities that aren't "real" so the programmers of SMW never coded what happens with them. This action can be used to get the execution code to jump to new places, and you can even overwrite certain execution code. (In C imagine writing out of the bounds of an array, and it can change memory elsewhere)

Do this enough times and if you're smart about it you could technically rewrite the entire game.

You can't think of it in terms of Java or C++ or C# because they're too high level and have too many fail safes to prevent you from doing anything.

Even C is too high of a language. You need to think of it in terms of the assembly code that the programmers used to write the game.

As for the sprites. They are also just 1s and 0s stored somewhere on in the memory. When you're rewriting the code just make sure you don't overwrite the sprite data and then call it at the correct times.

As for this video, I doubt it was real and they just split two games together in video editing, but the concept in itself is completely valid.

SNES games were written in a form of assembly code, but it isn't all 1s and 0s before being compiled...
en.wikibooks.org/wiki/Super_NES_Programming

valid SNES code looks more like:
.include "Header.inc"
.include "Snes_Init.asm"
VBlank: ; Needed to satisfy interrupt definition in "header.inc"
RTI

Also, even going by your premise, it's not like every combination of "1s" and "0s" is available by clicking buttons in a certain order. There are only so many options, and it had to be pre-existing somewhere else in the game. Plus, you encounter objects in a certain order in the game, and that's all you have to choose from - and you have to stay alive somehow while doing it.

On top of all of that, even buying the fact that you could do rudimentary programming using only in-game commands and object manipulation, I don't understand how you could add new graphics and sound effects that didn't previously exist on the cartridge - especially not with a few button clicks during 30 seconds of play-time.

I don't know, something just doesn't feel right about that.

As far as i know the sprites, the background and the music are all in game so were fine here.

after the code gets assembled its just a series of computer instructions, which are represented using some constant multiple of a byte (it depends on the processors architecture and i dont care enough to look it up for SNES).

each instruction holds the OP code (add, sub, sw, lw, branch, etc) and any data (registers, mem addresses, immediates, etc) that the instruction needs.

being that instructions are represented by a constant multiple of a byte, they are stored in memory via 1s and 0s.

Playing on specific levels and going through certain pipes can aid in controlling which entities are visible at any given time, but it is extremely difficult and you need to have a complete understanding of the memory diagrams for where everything is stored in memory to even begin doing anything.

Somethings are impossible, and i believe this video is one of those, but there is a large amount you can do with it.

To be fair a huge junk of it is just plain trial and error

If you understand how the memory is set up for a given game, and how the levels are set up, then you can systematically go through and modify the memory addresses you want.
Trial and error would take way too long.

Doesn't necessarily mean the way they did it was the best or most efficient (in the video for #10 you can see some goomba glitches),.

Well you need an emulator for that (or some skills in electronics) to get the exact memory address in order to extrapolate the next inputs needed for the desired output. I'm nut sure if all the guys involved in the process of that video had the skills or the tools to do so, that's why I assume some trail and error was involved.

You need an emulator regardless. The process used to change the memory involves using "virtual" controllers. The video in number 10 had something like 16 virtual controllers which a console in no way can support.