>>  ;; Internal utility functions
>> +(defun sieve-manage--set-internal-buffer-properties (buffer)
>> +  "Set BUFFER properties for internally used buffers.
>> +
>> +Used for process and log buffers, this function makes sure that
>> +those buffers keep received and sent data intact by:
>> +- setting the coding system to 'sieve-manage--coding-system',
>> +- setting `after-change-functions' to nil to avoid those
>> +  functions messing with buffer content.
>> +Also disables undo (to save a bit of memory and improve
>> +performance).
>> +
>> +Returns BUFFER."
>> +  (with-current-buffer buffer
>> +    (set-buffer-file-coding-system sieve-manage--coding-system)
>> +    (setq-local after-change-functions nil)
>> +    (buffer-disable-undo)
>> +    (current-buffer)))
>> +
>>  (defun sieve-manage--append-to-log (&rest args)
>>    "Append ARGS to sieve-manage log buffer.
>>  
>> @@ -175,10 +202,8 @@ sieve-manage--append-to-log
>>  `sieve-manage-log'. If it is nil, logging is disabled."
>>    (when sieve-manage-log
>>      (with-current-buffer (or (get-buffer sieve-manage-log)
>> -                             (with-current-buffer
>> -                                 (get-buffer-create sieve-manage-log)
>> -                               (set-buffer-multibyte nil)
>> -                               (buffer-disable-undo)))
>> +                             (sieve-manage--set-internal-buffer-properties
>> +                                 (get-buffer-create sieve-manage-log)))
>>        (goto-char (point-max))
>>        (apply #'insert args))))
>
> This still uses a less-than-elegant implementation that calls
> with-current-buffer twice.

Yes, true. But since `sieve-manage--set-internal-buffer-properties' is
used in two different places, the more elegant solution you suggested
above would require duplicating the body of the function in those
places. I just didn't see a better way. In particular because
`set-buffer-file-coding-system' and `setq-local' only work with
(current-buffer). If you can point me to code which can replace these
with something that takes BUFFER arguments, I can rewrite
`sieve-manage--set-internal-buffer-properties' and avoid using
`with-current-buffer'.

>>  (defun sieve-manage-encode (utf8-string)
>>    "Convert UTF8-STRING to managesieve protocol octets."
>> -  (encode-coding-string utf8-string 'raw-text t))
>> +  (encode-coding-string utf8-string sieve-manage--coding-system t))
>
> Why is the argument called utf8-string?  If it's indeed a string
> encoded in UTF-8, why do you need to encode it again with
> raw-text-unix? it should be a no-op in that case.  So please tell more
> about the underlying issue.

I chose the name as a hint to the user that the incoming string should
be UTF-8 encoded. But that is probably misleading since the string
itself doesn't have an encoding? So let's change the function to:

    (defun sieve-manage-encode (str)
      "Convert STR to managesieve protocol octets."
      (encode-coding-string str sieve-manage--coding-system t))

Regarding the potential double encoding: When sending data over the
network connection, `sieve-manage-encode' intends to make sure that
`utf8-string' data is converted to a byte/octet representation. I tried
to explain that in the doc string of `sieve-manage--coding-system':

    (defconst sieve-manage--coding-system 'raw-text-unix
      "Use 'raw-text-unix coding system for (network) communication.
    
    Sets the coding system used for the internal (process, log)
    buffers and the network stream created to communicate with the
    managesieve server.  Using 'raw-text encoding enables unibyte
    mode and makes sure that sent/received octets (bytes) remain
    untouched by the coding system.  The explicit use of `-unix`
    avoids EOL conversions (and thus keeps CRLF (\"\\r\\n\") intact).")

The original problem was that when communicating with the sievemanage
server, we need to handle length elements where we need make sure that
calculated values take into account that UTF-8 characters may comprise
multiple octets.

Even after reading the relevant sections of the documentation multiple
times I was (and am still) not sure what exactly the various coding
system settings do and how they interact with buffers and networking
functions. So forgive me if what I'm doing there looks weird to your
expert eyes.

When working on the original patch, I had several uhoh moments where
data sent to or received from the network seemed to have been
automatically modified by the coding system (unfortunately, I don't
remember the exact details). So I tried to eliminate any such automatic
modifications by using 'binary or 'raw-text encodings on code paths
which handle network data. Basically, my thinking was: 'better do things
twice/thrice/... before introducing new points of failure'.

>> @@ -244,8 +267,7 @@ sieve-manage-open-server
>>                   (open-network-stream
>>                    "SIEVE" buffer server port
>>                    :type stream
>> -                  ;; eol type unix is required to preserve "\r\n"
>> -                  :coding 'raw-text-unix
>> +                  :coding `(binary . ,sieve-manage--coding-system)
>
> Same question about encoding with raw-text-unix here: using it means
> some other code will need to encode the text with a real encoding,
> which in this case is UTF-8 (AFAIU the managesieve protocol RFC).  So
> why not use utf-8-unix here?

Same as above: I'm just not sure that this is the right thing.

But after thinking about it some more, I made the following change (as
an experiment):

1. set `sieve-manage--coding-system' to 'utf-8-unix (and update
   the doc string)

With this change, there are still no issues when connecting to my
managesieve server which still contains a script with a name that
contains utf-8 multibyte characters. Also, the test I wrote still works
with that change.

So if you think that this makes things clearer, I'm happy to make the
change. I just don't feel confident enough to do this without
additional guidance.

I was also experimenting with some additional changes with the hope to
to just use coding system settings instead of calling
`sieve-manage-encode'/`sieve-manage-decode'. But I couldn't get that to
work.

I added an updated set of Emacs 30.x patches with the changes described
above (plus an additional change in sieve.el which makes sure that the
sieve-manage buffer containing the list of available sieve scripts is
also using coding system 'utf-8-unix from `sieve-manage--coding-system').

> Should the addition of BYE support be mentioned in NEWS?

I can certainly do that if you think that this is useful. It just seems
to be more of an internal detail which probably doesn't mean much to
most users.

> On balance, I think the additional patches should go to master,
> indeed.  But let's resolve the issues mentioned above first.

Ok, awaiting further input...