Suppose we have the following archetypal menuitem and callback, typical of those written before custom pause menu control with "stay open" functionality was added in 0.2.2. Basically "pick this menu item, X will happen in response"

function _init()
 i=0
 menuitem(1,"increase",callback)
end

function _draw()
 cls()
 ?i
end

function callback()
 -- do stuff, e.g.:
 i+=1
end

Prior to 0.2.2 the pause menu behavior was:

• btns 0,1 do nothing
• btns 2,3 navigates menu
• btns 4,5,6 trigger callback and close menu
  • no arguments supplied to callback
  • callback return value is meaningless

With new features of 0.2.2+ the documented pause menu behavior is:

• btns 2,3 navigates menu
• btns 0,1,4,5,6 trigger callback
  • bitfield argument supplied to callback. btn0=0x01; btn1=0x02; btn4,5,6=0x70 (indistinguishable)
  • callback can modify menuitem text
  • callback can return true to keep pause menu open, else it closes

However, the actual behavior is:

• btns 2,3 navigates menu
• btns 4,5,6 trigger callback
  • menu stays open if callback returns true, else menu closes
• btns 0,1 trigger callback
  • does not respect callback return value of false, nor lack of a return value
  • menu stays open regardless

For the end user, this can lead to UI and UX issues.

• Using the above toy example, a user might press L/R multiple times on the menu item and think that nothing is happening due to the lack of feedback, only to discover the effects upon exiting the menu.
• More substantially, we might use a menu item to trigger "scene switch" which replaces _update and _draw functions, and change menu items accordingly. User expects menu to close and scene switch to take place in such cases, but L/R buttons would cause menu to stay open. Menu items would change immediately, but the game background behind menu will not be updated until after exiting the menu. This may lead to user confusion.

As it is btn 0,1 behavior is a strange mashup of it's old behavior and the new btn 4,5,6 behavior, and ends up neither here nor there. For preexisting carts, without updating code, there are now two different behaviors (for btns 0,1 vs btns 4,5,6) where only one was intended. And for developers, btn 0,1 do not offer the full control that btns 4,5,6 do.

It would be more consistent if btn 0,1 behaved the same as 4,5,6:

• legacy code works the same without changes, respond to all 5 buttons (up from 3) in the same way
• developers writing new code have the option to handle btns 0,1 and close the pause menu

For now, to prevent surprises, any menuitem not intended to respond to L/R buttons would have to explicitly ignore them in the callback:

function callback(b)
 if (b&112==0) return -- only proceed for btn 4,5,6
 -- now do stuff...
end