For bug 135636, I consider to use a special toolbar button for the "Encrypt" button.

I suggest a toolbar button that can show 2 icons next to each other.
The second icon would show whether the toolbar button is currently "automatically controlled" or "manually controlled".

The existing toolbar button already shows a state, and a changing first icon.
Different icons are used for encryption enabled and encryption disabled.

As of today, the button is only controlled manually - or - switched automatically based on a direct user action, such as clicking a second "enable encryption" or "disable encryption" elsewhere on screen (in a notification).

Bug 135636 suggests to automatically adjust the encryption setting, when changing the recipient list (to/cc/bcc) of a message that the user composes. (When adding another recipient, encryption for the message may no longer be possible, and bug 135636 asks to automatically disable encryption in that scenario.)

The additional complication is: The user should be able to manually override.

Let's say the automatic mode has encryption turned on. The user decides that encryption should not be used for this message. The user may click the toolbar button to disable encryption.

From this point of time, for this composer window, the user's decision should be "sticky". No further automatic changes should be made to the Encrypt mode.

I would like a way to visually indicate, whether we're currently in the automatic mode, or in the manual (sticky) mode.

Here is my idea to implement that:

The Encrypt button could show two icons. The first icon would be the existing icon (encryption enabled or disabled). The second icon would indicate the "switching mode" for this button.

When still in automatic mode, the second icon could be two gears, like this:
https://openclipart.org/detail/275576/gear-wheels

The intended meaning of the gears icon is: The state of this button may change at any time, based on automatic decisions made by Thunderbird.

When in manual mode (user has clicked the button, the user's decision is sticky), the second icon could be a pointing finger, like this:
https://openclipart.org/detail/131491/mouse-pointer

The intended meaning of the pointing finger icon is: The user has clicked this button, and the button remains in the state the user has chosen. The button will no longer change state automatically. The user may still click the button again to change state.

Questions for Thunderbird's UX experts:

(1) Would it make sense to show a button with two icons? [edited]
Do you think users could understand it?

(2) Do you think it would be possible to implement that?

(3) We have a challenge that the toolbar can be customized to show text, only.
How would we handle the second icon in that mode?
I'm afraid we'd have to use the same icon text in all customization styles.

If you don't like the above approach, we could use a different approach to visualize the states "automatically controlled encryption" vs. "manually controlled encryption".

With the above suggestion, the user couldn't control that mode. If automatic mode is allowed (because of a pref) then the composer would start in the automatic mode. As soon as the user clicks the Encrypt button, we're in manual mode, and the user cannot switch back to automatic (to avoid confusion).

We could e.g. use a read-only control somewhere somewhere in the composer window that visualizes this current mode.

I'm of course not a TB UI expert but may I give feedback?
I'm not sure if there is need for this UI. Regarding (1), to be honest, I think it's not obvious to the user: neither the suggested icons nor the principle. Here is my reasoning.

1. The whole encryption topic and the auto enable/disable is pretty complex. I'd try to hide the complexity from the user.
2. Does it matter if encryption mode is sticky or not? I don't think so because (a) if the user disabled explicitly and a mail address with key is added, Thunderbird shows a notification that encryption is supported. (b) if the user enabled explicitly and a mail address doesn't support encryption Thunderbird also shows a notification and even forces the user to act. (c) if the encryption mode is auto enable/disable, the users either are aware of it (because they chose the option in the account settings) or they are not aware and are not interested much in encryption anyway.
   In all cases what does the display of the sticky state help?

The intention of the sticky state is, to make the user aware that no further automatic decisions will be made. The user might be surprised if the automatic actions no longer happen.

The intention of the "you are in automatic mode" is to remind the user, that a current "encryption is enabled" state may change at any time.

Maybe both aren't strictly necessary. I thought it would be nice to have.

I would like a way to visually indicate, whether we're currently in the automatic mode, or in the manual (sticky) mode.

I really don't think this is necessary.
First we're affecting the cognitive burden of the whole composition experience, as well as adding extra elements that don't bring any real benefit and only force the user to "think" about what's happening to the UI.

Having automatic encryption is a specific user action, so users are aware of their current setting.
Enabling and disabling encryption manually is done from the same button.
When automatic encryption kicks in, the button is toggled.

There's no need for extra visual information to let the user know that they can still disable encryption and override an automatic option via manual interaction.
That's a pretty common and expected behavior of any software, as an opt-out action is expected to persist till the end of the session.

Furthermore, all of these actions are deliberately triggered by the user (setting up automatic encryption, and overriding it with the button), so nothing happens accidentally or unexpectedly, therefore there's no need for extra alerts, warnings, info, or button.

Doing what you propose would make the UI extremely complicated and non linear.
I recommend to not do anything here.

Alessandro, thanks for your feedback. It makes sense, it seems like I was trying to overengineer this.
I'll close this for now.