Sure!  Here you go:
L1: Asm(21788411E389010900EDB0) \ Asm(21E389E7EFF1421A4F131A4713131321959D0B0BEDB0)
L2: Asm(21788411448D010900EDB0) \ Asm(21448DE7EFF1421A4F131A4713131321959D0B0BEDB0)
L3: Asm(21788411699B010900EDB0) \ Asm(21699BE7EFF1421A4F131A4713131321959D0B0BEDB0)
L5: Asm(217884117F85010900EDB0) \ Asm(217F85E7EFF1421A4F131A4713131321959D0B0BEDB0)
L6: Asm(217884113796010900EDB0) \ Asm(213796E7EFF1421A4F131A4713131321959D0B0BEDB0)
This is untested, I just changed some hex values.  It should work, though.

Fair enough, but I'm using L1 and L2 for Half-Life and wanted an alternative.

This is how it works.  The first routine copies the name of the currently running program to the end of tempSwapArea (unless you specify somewhere else).  Thats all it does.
The second routine is where the magic happens.  It copies the name from tempSwapArea into OP1 and looks it up using ChkFindSym.  Then, it copies the length of the program into bc.  Then, it puts 9D95 (the location of the currently executing program) into hl.  Then, it places the location of the data according to the VAT into de.  Then, it ldirs everything from 9D95 into the saved program.
What this means is that because Axe copies everything from [] tags to the end of the program, if you modify it while running at 9D95, the last routine applies the changes to the saved program.
This works because TIOS doesn't run compiled Axe programs from their real location in memory.  It copies them to 9D95 first.  So to use these routines, here is an example:
Asm(...) (First routine)
[00->GDB1
{GDB1}+1->{GDB1}
Asm(...) (Second routine)
So the output from Axe looks like this, more or less:

1) First routine
2) {GDB1}+1->{GDB1
3) Second routine
4) ret      ;Leave the program
5) 00      ;GDB1 Points here

When you run the program, this is copied to 9D95 and executed.  When it hits line 2, the code at 9D95 changes to this:

1) First routine
2) {GDB1}+1->{GDB1
3) Second routine
4) ret      ;Leave the program
5) 01      ;GDB1 Points here

When it his line 3, the second routine copies lines 1 to 5 into the original location.  The saved program becomes:

1) First routine
2) {GDB1}+1->{GDB1
3) Second routine
4) ret      ;Leave the program
5) 01      ;GDB1 Points here

Without the second routine, line 5 would remain at 00.

At first glance, that looks correct.  Program write-back and SMC is kind of hard to explain to a non-assembly programmer, you are getting along with that description quite well!

Yep!  And here is another routine for use in Axe that works quite well, and will work even better once getkey support for ON is added.
Toggle Screen On/Off
(Adapted from the WikiTI version)
Lbl TS
Asm(DB10CB6F20053E03D310B93E02D310)
ReturnNote: This routine must be called as a subroutine, do not try to run it in-line if you don't want to exit your program prematruely and leave your user with a turned-off screen and no way to turn it on.

No, you call it, and if the screen is on, it turns it off.  If the screen is off, it turns it on.

Yay writeback!  Now i can add highscores to anything i want! ^^

So corect me if I'm wrong but running the asm code makes *all* data writeback?

Yeah, but from what it looks like there is no point where the data to be kept in the program is specified, so it seems to keep *all* the data

Then again, if you have 200 sprites in your program to begin with, enabling writeback won't mess with them unless you mess with them yourself, and it won't add to the size since they are already in the program normally.