The content of what used to be installed as
$OOO_BASE_DIR/share/registry/data/org/openoffice/Office/Calc.xcu is now part of
a larger file $OOO_BASE_DIR/share/registry/main.xcd, but the configuration set
/org.openoffice.Office.Calc/UnitConversion, and all its original content, is of
course still there (I assume that that is the relevant configuration data).

I see that the "in-line" documentation of CONVERT in the Calc Function Wizard
dialog states: "Converts a value according to a conversion table in the
configuration (calc.xcu) [sic, with a lowercase 'c']."  I find no mention of
Calc.xcu in the on-line help documentation of the CONVERT function, and no
mention at all that the conversion table can be extended by a user by manually
editing some Calc.xcu.

@oc:  Can you clarify the following, please:
(1)  My understanding is that this issue is not about a broken CONVERT function
(it still correctly obtains it data from the configuration), but only about the
Function Wizard mentioning a calc.xcu that does not exist.  Right?
(2)  Is there any documentation that a user can extend the conversion table?

@oc: ping?

@sb: Oliver is on vacation, I'll try to answer what I can, he showed me
a CWS build once before he left.

The CONVERT function is not broken, apparently the conversions were read
from the initial configuration, but somehow adding new conversions
wasn't possible, they weren't known to the application then. I just
retried using OOo_3.2.0_091210_unxlngi6_install.tar.gz from
sb111-instsets, but had NO problem adding a new conversion to
share/registry/main.xcd, it was known to the application after having
restarted it. We'd have to wait for Oliver to see if he did something
different.

The description in the Function Wizard certainly will have to be
changed. I don't think it was documented how exactly new conversions can
be added, the typical end user probably didn't know, but this feature
may have been used by enterprises to administrate daily exchange rates
of other currencies, for example. The online help has only "The
conversion factors are given in a list in the configuration."

For "ease of use" I'd prefer if the UnitConversion  node would be in
a separate file, but I guess given the rare use case this is not
justified.

Btw, the configuration files now consist of one long line of XML
elements, can't we at least have line breaks? Yes, I know xmlpp works
and XML editors probably would too.. anyway, would be easier to edit
using an ordinary editor.

Btw2, I like how schema and data are now in one file, but the <info>
elements with the descriptions are lost. Any plans to re-add them, and
if it was in separate schema files to not have them clutter up the
configuration itself? A configuration back-end now doesn't have the
chance to display them. Or did I miss something?

@er, re btw1/2:  .xcd files are generated from .xcs/.xcu files through
solenv/bin/packregistry.xslt, which removes "non-content" whitespace and
"documentation" elements that are ignored by the current configmgr
implementation (like <info>), following the rationale that those files are
mainly for programmatic consumption by configmgr (where speed is important, so
simply leave out everything irrelevant), and that manual modification is of
secondary importance only (and the dropped "documentation" elements are still
available in the original OOo source .xcs files, for reference).

@oc: please clarify how to proceed

Hi Eike, as discussed the best way would be to allow the changes via an extension

Funny guy, discussed with whom? Yes, an extension might be nice to have, but no,
I'm not the owner of this, especially not for OOo3.3, retargeting and
reassigning to requirements.

@sb: re btw2: without the <info> elements a generic configuration tool is not
able to display the descriptions of the actual configuration. It would have to
be updated for every release now.

Created issue 109323 for function wizard's description and help text.

@er, re btw2:  I am not sure a generic configuration tool is desired.  The
configuration files should be considered implementation details of configmgr. 
The stable interface is the configmgr UNO API and the mechanism by which
extensions can bring along .xcs/.xcu files.