<r​brunner7:monero.social> About moving `getSeedLanguage` and `setSeedLanguage`: I don't see any problem to move

<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.

<r​brunner7:monero.social> About moving `getRefreshFromBlockHeight` and counterpart: Yes to move again, no problem to move a few things

<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.

<r​brunner7:monero.social> I wouldn't move `setupBackgroundSync` and counterpart either.

<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 :)

<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.

<r​brunner7:monero.social> Hope that helps :)

<s​needlewoods_xmr:matrix.org> it does, thank you, much appreciated :)