Why not just:

let myWebApp = webApp {
    name "test"
    add_slot deploymentSlot

    settings ["my_setting", "test value" ]
    slot_settings ["my_slot_setting", “sticky_value” ]
}

or is that not a convenient api to deal with slot settings?

In ARM templates both slot and non-slot settings are specified in properties.siteConfig.appSettings property of Microsoft.Web/sites/slots resource. To make some of them slot-sticky we add another resource slotconfignames, type of Microsoft.Web/sites/config. So idea was to keep the similar logic also here.

Sure, but there’s no reason Farmer has to have the same API as the ARM templates, we are free make a more sensible API where we can. And that was my question, is it not more sensible to specify slot settings in a way similar to normal settings.

An issue with using slot_setting_names is that it looks like a separate thing from setting values now. I assume it should not be possible to add a slot setting name that does not correspond to a setting. With my suggested API it would not be possible to end up in an invalid state where there is a slot setting name, but no setting?

Of course another option is to validate the slot_setting_names so it only contains valid names. But I couldn’t find any validation or unit test for that in the PR. Wouldn’t that be a good idea to at least have that validation?
What would happen if I make a mistake with my slot setting names? Does the ARM deployment fail?

I got you. Yes, we can modify it to have Farmer style:
slot_settings ["my_slot_setting", “sticky_value” ]
and
slot_setting "my_slot_setting" “sticky_value”

I will update PR