This model will encourage people to use BaseFieldBridgeOptions as the base implementation. This will be future proof as we can offer a default sensible implementation.

BridgeOptions.java

public interface FieldBridge { //could be an additional interface if that's better
    [...]
    FieldBridgeOptions getOptions();
}

interface FieldBridgeOptions {
    /** 
     * List of properties read by the class bridge
     */
    String[] getPropertiesRead();

    /**
     * List of lucene fields needed to read stored value
     */
    String[] getLuceneFieldsInvolved();

    /**
     * Get field descriptor as exposed by the metadata
     */
    Set<FieldDescriptor> getFieldDescriptors(FieldDescriptor baseDescriptor);
}

class BaseFieldBridgeOptions implements FieldBridgeOptions {
    public static final String[] DEFAULT_PROPERTY = new String { "_DEFAULT_PROPERTY" };
    public static final String[] ALL_PROPERTIES = new String { "_ALL_PROPERTIES" };
    public static final String[] DEFAULT_FIELD = new String { "_DEFAULT_FIELD" };
    public static final String[] ALL_FIELDS = new String { "_ALL_FIELDS" };

    @Override
    public String[] getPropertiesRead() { return DEFAULT_PROPERTY; }

    @Override
    public String[] getLuceneFieldsInvolved() { return DEFAULT_FIELD; }

    @Override Set<FieldDescriptor> getFieldDescriptors(FieldDescriptor baseDescriptor) {
        Set<FieldDescriptor> result = new HashSet<FieldDescriptor>(1);
        result.add(baseDescriptor);
        return result;
    }
}
    

@hferentschik interesting thinking around FieldDescriptor.isOpaque but it seems we are back to mixing different concepts.
For example, we want to expose coordinates as the synthetic field which has no physical meaning and project coordinates_HSSI_Latitude and coordinates_HSSI_Longitude. In the range case it sort of make sense to not make them opaque actually and in the quad tree approach, projecting them does not make a lot of sense as we can't reconstruct the coordinates AFAIK.
But a "number" field projecting to different fields might be a good candidate.

What I am getting at I guess is that when someone uses the metadata API he will react differently to a synthetic field or a physocal field that should be hidden. For example the query DSL only works with simple field and synthetic fields. But a plain Lucene query cannot use the synthetic fields. We are again back to the use case problem.