14:31:32 <m-relay> <r​brunner7:monero.social> About moving `getSeedLanguage` and `setSeedLanguage`: I don't see any problem to move
14:37:17 <m-relay> <r​brunner7:monero.social> About `[get/set]ConfirmBacklog`: Personally, once I set the CLI wallet as a sort of reference, I would stick to that, even if I saw a way to eliminate a setting. But your idea works as well.
14:38:05 <m-relay> <r​brunner7:monero.social> About moving `getRefreshFromBlockHeight` and counterpart: Yes to move again, no problem to move a few things
14:43:38 <m-relay> <r​brunner7:monero.social> About `segregatePreForkOutputs` and similar methods that already exist but don't conform to the new naming convention that you establish: I am not sure there really is a definite "best" way to handle. I would probably add the old methods as "deprecated", but not move them, and put the new methods where they belong. Not moving the old methods helps a tiny bit to see what happens when reviewing.
14:46:37 <m-relay> <r​brunner7:monero.social> I wouldn't move `setupBackgroundSync` and counterpart either.
14:49:33 <m-relay> <r​brunner7:monero.social> About adding a more or less redunant `getDeviceName`: Personally, I weight avoiding exception higher than saving one or the other method. Over many years I have to come to really dislike exceptions in APIs :)
14:53:25 <m-relay> <r​brunner7:monero.social> I would vote for an `ExportFormat` enum. If you have a call to set the export format with a boolean `use_binary` any future third format would force you to change the API which is bad.
14:54:28 <m-relay> <r​brunner7:monero.social> Hope that helps :)
19:47:26 <m-relay> <s​needlewoods_xmr:matrix.org> it does, thank you, much appreciated :)