Here is how the text behaves in word, in the other system where I generally paste, a library system software and originally on Zotero.
https://s3.amazonaws.com/zotero.org/images/forums/u4229194/9use0yp4hj2pwprj61ca.png

At least concerning the Aleph input, this should come out fine in a browser if using a modern font. There, IMO it's Aleph's fault.

The background here is most likely that you can encode accented characters either in a composed form (base char + accent char in one code point) or decomposed, that is separate base char in a code point and composing accent char in a code point, in this order. Depending on the system and software you use, it's often normalised to on or the other. Many modern fonts come with the informations built in how to compose the accented form from the composing components (i.e. where does the accent have to go above or below the base glyph). Aleph, as old as it is, can't handle that correctly so you see the underlined tilde which shows you that it is a composing tilde which is differently encoded than a non composing tilde (~). When you publish this record to Primo or another Opac you should see it correctly composed because the browser knows how to handle it.

EDIT: I think, I remember darkly that Aleph in fact can handle it and only the font doesn't provide the a+tilde composing. IIRC setting Aleph to use a different font can fix it and I did that once. But we don't have Aleph any more so I can't tell exactly what to do.

Yes, applications that expect a certain format often do normalize to that on import, save or even export.

It seems that the Word spell checker doesn't handle decomposed forms in any language. Just tried it with concentração, as well as with English fiancée and German möglich.