JIRA's CustomField class implementation does not respect JiraRendererPlugin.transformFromEdit()

Special thanks to the customer and developer Jens Doll. Technical description and impact analysis is quoted from him
Technical description:

The semantics of the above mentioned method is stated in the Java doc of the interface com.atlassian.jira.issue.fields.renderer.JiraRendererPlugin:

/**
  * This allows the renderer to perform a transformation on the submitted edit value before
  * storing the value in the system. This can be useful if the value being submitted is
  * a different format (i.e. html markup that the edit control generates), than the system
  * expects to store (i.e. wiki markup). <b>NOTE: this method need not do anything if the
  * system is happy to store the value the edit control produces.<b>
  *
  * @param editValue is the value produced by the edit control.
  * @return the value in a form that the system expects to store.
  */
public Object transformFromEdit(Object editValue);´

But as stated, the CustomFieldImpl class disrespects the return value of the function transformFromEdit() and thus making this method completly worthless.
The excerpt from CustomFieldImpl.java shows this:

private Object processValueThroughRenderer(FieldLayoutItem fieldLayoutItem, Object value) {
  // ..
    rendererManager.getRendererForType(rendererType).transformFromEdit(value);
  // ..
  return value;
}

Interestingly other field implementations do indeed respect the return value. As example DescriptionSystemField.java is shown here:

public void updateIssue(FieldLayoutItem fieldLayoutItem, MutableIssue issue, Map fieldValueHolder) {
  // ..
    // give the renderer a change to transform the incomming value
    String desc = (String)rendererManager.getRendererForType(rendererType).transformFromEdit(getValueFromParams(fieldValueHolder));
    if (TextUtils.stringSet(desc))
      issue.setDescription(desc);
    else
      issue.setDescription(null);
}

A fix for this would be just adding value = in CustomFieldImpl.java before the call to the method. Resulting in something that looks like:

private Object processValueThroughRenderer(FieldLayoutItem fieldLayoutItem, Object value) {
  // ..
    value = rendererManager.getRendererForType(rendererType).transformFromEdit(value);
  // ..
  return value;
}

Note that this bug might be in more versions than the one stated here, 4.2.2 and 4.3 are the version where the bug was confirmed within the source.

Impact analysis

As for the impact analysis:

• For any vanilla JIRA installation (this means a out-of-the-box installation with no additional plug-ins whatsoever) the impact is negligible, since no renderer initially shipped with JIRA rely on this feature. (For example, the "Wiki Style Renderer" will just store the contents of the field as entered by the user in the database with no transformations applied.)
  This is probably the reason why this bug was never discovered.
• As it comes to plug-in developers this may render (huh!) some custom developed renderer implementations impossible since a server side transformation from returned values is not possible without this feature. One possible way to circumvent this is to apply all transformation that are necessary for a renderer with Javascript on the client side (in the HTML document, so to speak). But this makes an implementation of an renderer rely on Javascript to be enabled in the browser and thus effectivly prevents any unobtrusive Javascript implementations.

Steps to reproduce the problem
Jens Doll has created us a plug-in which has a renderer which is simply supposed to change the characters from lowercase to upper case. While it works as expected on System Fields, such as description, it does not work on custom fields: