ofParameter::makeReferenceTo introduces problematic event listener behavior

I would like to be able to figure out which ofParameter is "sending" a value using the classic event syntax (e.g. void onFloatParameterWithSender(const void* sender, float& value);), but private internal value changed pointer means that the source of the data can be confusing ...

...
    void onFloatParameterWithSender(const void* sender, float& value);

    ofParameter<float> parameter0;
    ofParameter<float> parameter1;

And a setup like this:

void ofApp::setup()
{
    // set up a listener for parameter 0 
    // in the callback (sender == &parameter0) is true
    parameter0.addListener(this, &ofApp::onFloatParameterWithSender);

    // set up a listener for parameter 1
    // in the callback (sender == &parameter1) is true
    parameter1.addListener(this, &ofApp::onFloatParameterWithSender);

    // make parameter1 a reference to parameter0 (watch parameter1 listeners disappear)
    parameter1.makeReferenceTo(parameter0);
    // trying to re-add parameter1 listeners is a a no-op because this listener already exists.
    parameter1.addListener(this, &ofApp::onFloatParameterWithSender);

    // now, in the callback (sender == &parameter1) will never be true because it is a reference
    // to parameter0's internal data.
}

Perhaps I'm just not thinking about this the right way, but I'd propose that we need to document the internal workings of ofParameter better or figure out a way to better control the fact that makeReferenceTo will make listeners quietly disappear when their internal data is replaced by the target's shared data.

Currently, if I want to bind a parameter to my gui (and make it appear that a gui widget is the source of the data), I have to add a layer of abstraction which automatically subscribes to the events of the newly referred parameter and then forwards them with the appropriate gui-sender pointer.

Start by inspecting ofParameter::makeReferenceTo and the addListener behavior described in the issue, then reproduce the parameter0/parameter1 setup with the classic sender callback. Determine how listeners and sender pointers behave after parameter1 references parameter0; the work is done when the behavior is documented or the listener handling matches the intended sender semantics.