The unused codes remain there in the original location where you compiled it. You can overwrite those bytes if you want but it is not recommended to do so as you can accidentally end up removing bytes important for game data and/or parts of some other script, unless you are absolutely 100% certain in what you are overwriting/removing.
Usually the ROMs have quite a huge amount of unused safe space, which makes it okay to make errors several time and recompiling the same script multiple times without removing the old ones. And it takes quite a while to run out of these free spaces and so removing/overwriting old scripts aren't necessary quite often.
However you can still choose to remove them. One thing you can do is open the script in XSE with refactoring turned off (see in Decompile Options) and your ROM in a hex editor, something like HxD. You will see parts of the scripts in XSE with #org 0xoffset in the start and go to those offsets in HxD and manually fill the bytes from there with "FF"s. If you have overwrote all the bytes in that place with FF, then you have successfully removed the script from existence and that space is once again free to use to compile another script. However, the issue is how many bytes you should replace with FF and how you can ensure that only the unwanted script is gone.
In XSE, if you press F1, you can see that each command has a corresponding byte and there is a portion that explains how many bytes it takes for that command to be written. You can use these info. For example, the command setflag has a byte 0x29 and it needs 3 bytes. Of course because when you write something like 'setflag 0x828' in XSE and then compile it, the game translates it into three bytes: '29 28 08'. The first 29 tells the game that a flag needs to be set and the next two bytes tell the game which flag to set. Notice how the 0x828 becomes 28 08, you take two pairs of numbers and flip the pair of numbers. Another example is how 'goto 0x08AB69CD' becomes '05 CD 69 AB 08'
The point is, if you have a script like this that you wanna get rid of:
#org 0x168CAE
compare 0x4056 0x0
if 0x1 call 0x8168CBA
end
#org 0x168CBA
sethealingplace 0x1
return
then going to 0x168CAE in HxD will show you these specific bytes: 21 56 40 00 00 07 01 BA 8C 16 08 02 and in 0x168CBA, you will see: 9F 01 00 03
You can check byte by byte how the bytes correspond to the XSE commands but you can do this in short. You can see that the command 'compare' has a byte identity of 21, so '21 56 40' definitely means 'compare 0x4056' and 'end' is represented with a byte 02. Thus, if we replace all the bytes from 21 upto that 02, the entire first part of the script i.e. the part under #org 0x168CAE will be gone.
Another way thing to do is the following. But first look at two different way to write the same script:
The first way is how max times we write our scripts. XSE finds spaces starting from 0xA30000 and places the scripts in safe empty places converting them to bytes. However if you write the script like the second way, XSE puts the script at the location 0xA30000 forcefully regardless of whatever there was in the first place. You can use this to overwrite things that already exist in a certain address. And in my opinion:
this is more dangerous to do than removing scripts with HxD mentioned above and must only be done if you are over 9000% sure about doing something this way.
However, it is still handy if you want to make small byte changes. Say, there is a huge script where one line says: fadesong 0x1AB which means the background music fades to song no 1AB. But lets say, you dont want it to play song 1AB and instead want 10C to be played. So, you can open the script in XSE with refactoring turned off, goto the line with fadesong 0x1AB and replace it with fadesong 0x10C and click compile. Voila! You changed part of a script without taking up another big chunk of space! You can use it to fix these kinds of error in your codes. Like, say you accidentally put 'compare 0x4050 0x69' but you wanted to put 'compare 0x4050 0x2', etc.
Sorry if this turned into a little too big of an essay xD I get carried away when I am talking about XSE :P
