Gidday, Richard,
Yes, there are some very good suggestions there. It’s a pity that Google and Microsoft are not concerned with doing the right thing, but only with pandering to the majority who don’t know how to use email (“reply to all”, as another example, appears to be a struggle for the vast majority).
I don’t know if “spammy” is quite the right word choice for the inability of people to deal with a larger number of emails than “usual” (‘spam’ is unsolicited commercial email). However, you are right that there is a definite impedance mismatch with users’ expectations for email, versus DC’s instant messaging paradigm. This is compounded by people not knowing how to use email properly (for example, unable to create filters to automatically deal with certain emails, unable or unwilling to “reply all” to a group email, and the opposite, unable or unwilling to send private replies privately, instead of to the whole group).
I completely agree that DC promotes interoperability with normal email users, and so should make every reasonable effort to ensure that the experience is acceptable to those users of typical MUAs (any non-Delta Chat MUA, I suppose).
Unfortunately, inappropriate subject lines are the norm, rather than the exception, as one might think after reading by my previous comments and explanations. When one sends a message (email) the first time in a week or two weeks, it is not acceptable to have the subject line from last week or the week before that (which quite likely was not very appropriate even back then). Your suggestion about the timeout behaviour would appear to be a reasonable fix for that issue.
One reason this behaviour is unacceptable is that the receiver has no idea that you didn’t set the subject, but that your “silly” email program did it for you, and not only that, but that you, as the sender, have no idea what the subject line actually is. (Impedance mismatch.)
Although uninformative, it is much more acceptable (than the current practice), and in line with the instant messaging paradigm, to always set the subject as “Message from NAME”. Or possibly better, “Instant message: NAME <=> NAME”, which would thread just nicely on broken MUAs that thread on Subject instead of in-reply-to headers.
Regarding your specific ideas or suggestions, in order.
-
This seems a quite workable idea. I think you are right that after archiving a conversation, there would be no reasonable expectation that the Subject line should remain unchanged. A possible exception may be if one receives another reply to a chat that has been archived.
-
A user-configurable chat idle time in hours or days would be ideal, too. I assume most people would be happy with an idle time between one and seven days (or infinite, if they don’t wish to use that feature).
-
A simple “Subject: This is the new subject” followed by a new line seems easy both on the user and the developers. Documentation would alert the power user that this may start a new thread in broken MUAs. To actually start a new thread (which is orthogonal to changing the subject, instead of the word ‘Subject’, use the word, ‘Thread’: “Thread: This is the subject of the new thread” followed by a new line. A subject that is too long would begin to print on screen in red.
-
Obviously, this only applies in the presumably usual case when the user does not explicitly set the new Subject (after archiving a chat, for instance, or the very first email sent to a particular recipient).
Yes, I don’t think anyone wants to turn DC into a “proper” email client, yet we agree that we do wish to avoid alienating those with whom we are communicating! 
Here is another important impedance mismatch to think about. When the remote user sends you an email, or replies to an email, they often set or change the Subject, and sometimes this_information_is_not_repeated_in_the_body or alternatively, you need to see the subject line in order to interpret the body correctly. This will result in incorrect communication because the DC user never sees the subject! (Unless, like me, they sometimes check in another MUA.)
I believe this probably means it is mandatory for acceptable interop with normal MUA users, that the current subject line be always visible in some way! And if it’s going to be visible, it might as well be editable, too. (Obviously, this is not required or desired for plain Delta Chat to Delta Chat messaging.) Having the subject appear while hovering the mouse over a message might be an acceptable compromise for desktop Delta Chat, but obviously not for mobile.
David