The bug is that tk_strictMotif (which uses self.tk.getboolean() itself) returns 0 instead of False. I used the "nested" command to point out, that self.tk.getboolean() is broken when used with wantobjects=True, because it does *not* return proper boolean values , i.e. True or False. It is probably the reduction to handling strings only that you mentioned that causes this wrong behavior, because with wantobjects=True self.tk.call() will convert the "0" tk_strictMotif returns into 0 which is not handled properly. With wantobjects=False, it will retunr True/False as expected. Its behavior is not consistent, *that* is the bug.

But to be honest, personally I don't give a dime if these calls return True/False or 1/0, I just wanted to make clear why I explicitely converted the output of self.tk.getboolean() in my tk_busy_status function. I believed that proper boolean values (True/False) were the desired thing.
I personally agree with you about the busy_status function, my construct is not necessary, if someone does not like it to return 0/1 , tkapp.getboolean() should be fixed instead.
And again I admit that I don't remember why I used that construct instead of just passing the result to bool(). I am quite sure I had a reason for this when I started to use this construct first some years ago, but back then tkapp.getboolean() behaved differently (and worse), some of which was apparently fixed in the meantime.

And one more time about _configure():

"I like elegancy..."

So do I, but can't expanding the functionality of a method by adding a new option be considered a more elegant solution than entirely changing its behavior with the effect of having to change a number of other things, too? (though I admit that the name for this option I picked first should seriously be reconsidered if it's supposed to be called "elegant", I confess that I am notoriously dumb in inventing names :)