A typical interface looks like:
    DEF MyToaster Toaster {
        isA Separator
        fields [ SFColor READ sideColor SFBool READWRITE handleDown ]
        sideColor 1 0 0
        handleDown FALSE
        ...                            # Some geometry
        DEF Side Separator {
            Material { emissiveColor USE MyToaster.sideColor }
            ....     
        }
        Switch {
            whichChild USE Toaster.handleDown
            { .. handle up geometry .. }
            { .. handle Down geometry }
        }                     
    }
In this example we declare that two of the fields of nodes of the class Toaster are accessable, the color of the side is read-only, the "handleDown" can be written to in order to change the state of the Toaster.
    DEF MyChangableToaster ChangableToaster {
        isA Toaster
        fields [ SFNode READWRITE toast ]
        toast { ... }           # geometry for default toast
        .....
        Separator { 
            Transform { ... }
            USE MyChangableToaster.toast    # Draw it here
        }             
    } 
In this case, some external behavior could change the "toast" field, to replace it with a Bagel.
Note that we still only have backwards references, from the USE to the place its defined. Also note that as for any use of "isA" the ChangableToaster inherits the READWRITE field "handleDown" and the READ field "sideColor".
   DEF InlinedToaster WWWInline { "http://foo.bar/changableToaster.wrl" }
   Switch { 
        whichChild InlinedToaster.handleDown 
        { ... } # handle Up action 
        { ... } # handle down action
    }           
    DEF Toaster1 WWWInline { "http://foo.bar/changableToaster.wrl" }
    DEF Toaster2 COPY Toaster1
Now, the handleDown field of these two toasters can be changed independantly.
   Prototype {
        DEF InlineToaster WWWInline { "http://foo.bar/changableToaster.wrl" } 
   }
   DEF Toaster1 USE InlineToaster
   DEF Toaster2 USE InlineToaster
It has the advantage that now all the instances of InlineToaster can be identical, and if the Toaster is not used it won't be rendered, and deleting instantiations of the toaster can no longer have the nasty side-effect of deleting the Toaster class.
It behaves exactly as the nasty hack
    Switch { whichChild=0 ..... }