bug#20623: XML and HTML files with encoding/charset="utf-8" declaration loose BOM; Coding system is reset from utf-8-with-signature to utf-8 on save

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 11 Aug 2018 12:13:41 +0200
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: monnier@iro.umontreal.ca, rgm@gnu.org, sledergerber@gmx.net,
> 	a.s@realize.ch, 20623@debbugs.gnu.org
> 
> On 2018-08-11 12:15:31 +0300, Eli Zaretskii wrote:
> > In this case, I cannot but express my extreme surprise to see such a
> > minor issue described as "grave".  The alleged data loss is minor, if
> > it exists at all (the BOM is not data important for the user,
> 
> You're completely wrong. The presence of BOM or not is very important
> for some applications, such as Firefox (not to determine the charset,
> but the MIME type of local files).

Please provide the details, including the use case, if possible.  I'm
still in the dark regarding the importance of the BOM in UTF-8 encoded
HTML stuff.

> It can be repaired, but the problems are the user doesn't know
> what's going on and this breaks things.

I agree about the user not knowing, but that doesn't yet qualify as
"data loss", which has an widely accepted meaning.

> If some package removed the execute permission of some utility in
> /bin, this would also be a grave bug, though it can easily been
> repaired.

Well, I disagree about the "grave" part, because that means the
package is unusable, causes data loss, or introduces a security hole
allowing access to the user account.  None of that is true in the case
in point.