thanks for the answers.
glad you've got the main fix working.
if you were to do the chunk of code ending at 000e1503 earlier on (upon the first item's target confirmation), and found a more permanent variable to hold the first Item ID, that'd enable a more complete fix. incrementing the quantity of an Item ID as opposed to simply an Item Slot would need more code space if written manually. however, i wouldn't be surprised if the game already has an Add_Item_ID_to_Inventory function that you can call. if there isn't or it's unknown, is there any free space where you could put a dumb loop to track down the first slot that holds a given item?
------------------------
EDIT:
okay, here's the above with denser commenting (mainly for my own reference, since you probably already know what it does from having made those charts):
000e14a4: ori r2,r0,0x0002
000e14a8: lui r3,0x800f
000e14ac: lbu r3,0x38a4(r3) // 800F38A4=02 -> Phase 2 of W-Item
000e14b0: nop
000e14b4: bne r3,r2,0x000e156c // branch if phase not 2?
000e14b8: ori r2,r0,0x000a
000e14bc: lui r3,0x800f
000e14c0: lbu r3,0x389d(r3) // 800F389D=0A -> W-Item Menu
000e14c4: nop
000e14c8: bne r3,r2,0x000e156c // branch if menu ID not 10?
000e14cc: nop
000e14d0: lui r2,0x800f
000e14d4: lhu r2,0x562c(r2) // 800F562C -> Load position of first item used.
000e14d8: nop
000e14dc: sll r3,r2,0x01
000e14e0: addu r3,r3,r2
000e14e4: sll r3,r3,0x01
000e14e8: addu r3,r3,r19 // (position of first item * 6) + constant
000e14ec: lbu r2,0x0002(r3) // get quantity of first used item
000e14f0: nop
000e14f4: bne r2,r0,0x000e150c // branch if nonzero
000e14f8: nop
000e14fc: lui r2,0x800f
000e1500: lhu r2,0x314e(r2) // 0x800F314E -> Load ID of first item used.
000e1504: nop
000e1508: sh r2,0x0000(r3)
000e150c: lui r3,0x800f
000e1510: lhu r3,0x562c(r3) // 800F562C -> Load position of first item used.
000e1514: nop
000e1518: sll r2,r3,0x01
000e151c: addu r2,r2,r3
000e1520: sll r2,r2,0x01
000e1524: addu r2,r2,r19 // (position of first item * 6) + constant
000e1528: lbu r3,0x0002(r2) // get quantity of first used item
000e152c: nop
000e1530: addiu r3,r3,0x0001 // Add 1 to it
000e1534: sb r3,0x0002(r2) // save new value
000e1538: lui r3,0x800f
000e153c: lhu r3,0x562c(r3) // 800F562C -> Load position of first item used.
000e1540: nop
000e1544: sll r2,r3,0x01
000e1548: addu r2,r2,r3
000e154c: sll r2,r2,0x01
000e1550: addu r3,r2,r19 // (position of first item * 6) + constant
000e1554: lbu r2,0x0002(r3) // get quantity of first used item
000e1558: nop
000e155c: sltiu r2,r2,0x0064 // is it less than 100?
000e1560: bne r2,r0,0x000e156c // branch if so
000e1564: ori r2,r0,0x0063 // Quantity limit (99)
000e1568: sb r2,0x0002(r3) // save capped quantity
000e1534 thru 000e155b is a big block o' repetition. unless there's something i'm missing that can branch to the middle of that, skip all that crap. we only need to load the quantity once, and we only need to save it once.
the "dumb loop" i mentioned above to track down a slot with matching Item ID can go further up. is 800F562C normalized to the first item slot; that is, will it hold 0 when the first W-Item used was in Slot 0? hopefully, that's the case, and the constant offset is confined to r19; that'll make the search loop easy to write. but if not, and 800F562C includes some constant, then i need to know what that value is.
also, i'm hoping that 0x800F314E indeed holds the ID of first W-Item used all of the time, and isn't one of the things that's clobbered by an intervening Morph? (i'd previously assumed the worst and discounted the utility of this variable despite your clear commenting of it. but then i realized its loading is skipped over most of the time, so there's a good chance it's *not* culpable for incrementing the wrong item.)
anyway, assuming the above two questions have the pleasant answers, then it should be fairly easy. we start at Item Slot 0, and check for an Item ID that matches our first chosen one. if it matches, we increment quantity there. if not, we proceed to the next slot by advancing a counter by 6, etc.
----
EDIT 2: actually, as a compromise, we should check for an Item ID match at the 800F562C slot before embarking on the possibly slow loop. takes more space than dropping that 000e14d0 code, but probably worth the speed savings it has 99+% of the time.