After looking at the previous issue https://github.com/twbs/bootstrap/issues/26904
And play with the associated codepen : https://codepen.io/Johann-S/pen/GBqoZG?editors=1111
I could still reproduce the use-case in current documentation on 3 way radio toggle buttons :
https://getbootstrap.com/docs/4.3/components/buttons/#checkbox-and-radio-buttons
1 - browse the input element with keyboard
2 - change the selected item using keyboard arrow
3 - look in the console document.getElementById('option2').checked or other optionid the current value isn't the visual one
Works well when using mouse
My first tests :
event.preventDefault() from plugin initialisation state change well with keyboard$(document)
.on(Event.CLICK_DATA_API, Selector.DATA_TOGGLE_CARROT, (event) => {
// event.preventDefault()
First tests doesn't show anything is broken by removing this

confirmed. sigh, these pretend toggles are going to be the end of me, i swear...
i suspect the preventdefault is a remnant of the old way in which these buttons were coded (seem to remember that it wasn't the actual <input> that ever received focus, but the parent element, and we then had to fake-click the hidden <input> etc). i'll have a look tonight, as i'd really like to put this to bed once and for all ;)
I need to check further but I think the click event is took by the label, and the keyboard event is took by the input element.
removing the event.preventDefault() ends up breaking the checkbox button just before those radio buttons. urgh, so much ugly fugly code in there...can't wait to ditch this completely for radios and checkboxes and just go the pure CSS route...the button plugin just tries to handle too many disparate cases and it all gets messy with the different way radio buttons are handled...
oh, it seems the checkbox is also broken in the current version anyway when using keyboard. sigh...
I tested this component with nvda 2019 and I agree with you : Checkbox and radio buttons doesn't change underlying input checked state.
Think this issue can now be closed following #28834 (should have autoclosed but didn't...)
Most helpful comment
i suspect the preventdefault is a remnant of the old way in which these buttons were coded (seem to remember that it wasn't the actual
<input>that ever received focus, but the parent element, and we then had to fake-click the hidden<input>etc). i'll have a look tonight, as i'd really like to put this to bed once and for all ;)