I think you can correct this problem even now. My proposal is: try modelling
this situation as a label for link EClass C with small addition: text for
this label should be loaded/stored in a different element (associated EClass
B) I have two suggestions how to implement it now:
1. Create derived property for link element (EClass C) like: BLabel. Re-generated
model code and implement properly generated getBLabel()/setBLabel() methods
to load/save value into associated instance of EClass B. Use this property
in a FeatureLabelMapping created below this LinkMapping in .gmfmep model.
2. Use LabelMapping instead of FeatureLabelMapping to model this link label.
As a result generated LabelEditPart (WrappingLabelEditPart ?) will call ParserService
from its getParserMethod(), but generated ParserProvider will not return
any parser for specified ParserHintAdapter parameter - in this case used
is responsible for registering/returning appropriate parser implementation
using GMF ParserService. As a next step you have to implement your own ParserProvider/modify
generated one to return proper IParser implementation for this ParserHintAdapter.
IParser interface is not so complex, so you can implement it and load/save
label text into EClass B instance associated with EClass C instance passes
ad a parameter into this IParser implementation.
This is another way - in case you can not modify domain meta-model you can
still use arbitrary model element property value to visualize link label
by implementing custom parser.