> [...]

> You need to specify the desired encoding on this line:

> \usetypescript[palatino][ec]

Hi Taco,

Thanks for your attention.
Indeed I had tried to add the encoding option, but then using either [ec] or \defaultencoding there appears a conflict with \enableregime[utf]. For instance,

\enableregime[utf]
\starttext
\usetypescript[palatino][ec] % or [\defaultencoding]
\setupbodyfont[palatino,12pt]
Here we are using the font \fontname\font.
And these are some diacritics: é, ç, à, ô, î.
\blank
\input knuth.tex
\stoptext

is typeset with Palatino, but then the diacritics are not typeset. On the other hand before the current version I used to use such settings even without specifying the encoding (that is
\usetypescript[palatino]
instead of \usetypescript[palatino][ec]). For the time being I avoid using non lmr fonts in my documents, but this indeed changes the pages I had before (however for the kind of things I do, this is not an issue...).

> 2) Generating a format with XeTeX, that is creating XeConTeXt, is now
> possible but still MetaPost code is ignored in the resulting PDF file.

This is a problem in the XeTeX engine. It always uses the ^^-quoted
form on every byte value below decimal 32, which basically makes it
impossible to create a valid input file for metapost: There are no
line endings written to in the generated file, but instead there are
three-byte sequences, like ^^J or ^^M.

This is why the new linux executable has the -8bit switch. That may
be needed (or even working already) in the OsX version as well.

Thanks for the insight. I understand that we have to wait for a change in XeTeX.

[...]
The (perl) compatibility scripts will stay around for fairly long time
to come, so there is no reason to panic yet. ;-)

Thanks for the assurance... I was only reporting a minor concern, shared by some other people on the list.

Cheers: OK