For future reference, if anyone is wondering why the font chooser is so complicated to use in a way that makes sense across platforms, here is its current behaviour...

From the manual:
 - configure -font is the font currently shown or font shown when dialog is initially shown (neither guaranteed on all platforms)
 - implementation-dependent which actions result in callback being called and event being sent

Windows
 - modal; show blocks until dismissed, cannot interact with other windows
 - ok/cancel
 - apply button added if a command option is specified
 - with command (apply button present)
     - if apply: callback generated with font currently set in dialog, event generated [configure -font is NOT updated]
     - if ok: callback generated with font in dialog, dialog closed, event generated, configure -font not updated
 - if no command (no apply button)
     - on ok, get event, configure -font not updated (correct, since dialog not visible)
 - fontchange event not generated if option is set in code

X11
 - not modal; show returns immediately, can interact with other windows
 - ok/cancel
 - apply button added if a command option is specified
 - with command (apply button present):
     - if apply: callback generated with font currently set in dialog, event generated [configure -font is NOT updated)
     - if ok: callback generated with font in dialog, dialog closed; no event, configure -font NOT updated
 - with no command (no apply button):
     - no event generated, configure -font NOT updated
 - fontchnaged event generated if option is set in code, configure -font updated
 - configure -font never updated by user interaction
 - conclusion: need to set command, hold onto current value returned

macOS
 - no ok/cancel buttons, works like a palette
 - non-modal; show returns immediately, can interact with other windows
 - BUG:can appear when tk first loaded (sometimes..)
    - happens when left open on previous launches and program exited abnormally e.g. ctl-C in terminal
    - ~/Library/Saved Application State/com.tcltk.wish.savedState/windows.plist still holds font chooser
    - if so, -visible initially is false, but is true after idle... no intervening <<TkFontChooserVisibility>> event
    - will segfault if set options e.g. font
    - workaround: hide on startup
 - fontchange event generated on every change in dialog, configure -font updated to font in dialog
 - fontchange event generated when option set in code, configure -font updated to font in dialog
 - command callback (if specified) invoked on every change from user (not in code), configure -font updated