termux-dialog radio results when tapping CANCEL are inconsistent

This is both a bug (minor) and feature request (also minor) regarding termux-dialog radio:

The bug:

termux-dialog radio -v "Option1, Option2"

When tapping either on CANCEL or somewhere outside the dialog (with or without having a radio button selected) this may return the following:

{
  "code": -2,
  "text": ""
}

If you keep running the same command and doing the above, the results are consistent. When you select an option, say the second one, and tap on OK, this will return:

{
  "code": -1,
  "text": "Option2",
  "index": 1
}

Now whenever you run termux-dialog radio, even after restarting the session, and tap on CANCEL or somewhere outside the dialog (with or without having a radio button selected), the results will always be:

{
  "code": -2,
  "text": "",
  "index": 1
}

i.e. it remembers the previously selected index and it returns that as well. To get rid of the additional/false parameter, you have to tap on OK without having anything selected, which will return:

{
  "code": -1,
  "text": ""
}

After that, when repeating the above (tap on CANCEL or somewhere outside the dialog with or without having a radio button selected), the results are correctly returned again without an index:

{
  "code": -2,
  "text": ""
}

Until you repeat the procedure and get again the false index result, etc.

This is not a big deal obviously but I noticed this while trying to determine the difference between tapping CANCEL or tapping outside the dialog. Which apparently has no difference.

The feature request (or question in case this can be done):
Is there a way to differentiate between the two and determine which has happened?

Start by reproducing the termux-dialog radio -v "Option1, Option2" cases for OK, CANCEL, and tapping outside the dialog, including repeated runs after selecting an option. Trace the radio dialog result handling and determine whether the observed index persistence and the distinction between CANCEL and outside dismissal can be addressed; done means the returned JSON is consistent and the two dismissal paths are clearly differentiated or documented as equivalent.