What is our targeted feature set for the MVP
I think either we recreate a car profile from scratch or add certain, more requested features like “avoiding” certain highways or ferries, or changing preferences of official bike routes.
Do we want to recreate the current profiles(car, foot, bike) and only good forward with the new approach?
Yes, at least at some point.
How do we deal with versioning?
Like we currently deal with backward compatibility: we would not do versioning and just introduce the change or remove features. That is the advantage of still being at 0.x 
No, not yet. My main goal was more to tweak the current flag encoders without Java.
and everything in between .
The task is already relative big, even without recreating FlagEncoders via “profiles” , so I’m a bit more leaned towards doing this later. But maybe this is the wrong approach. As you are definitely right that this would show the completeness of this approach. The big problem is that FlagEncoders do so many things like calculating “cached values” (like accessEnc, averageSpeedEnc) from tags, calculating turn restrictions and probably more that we would need to refactor. Furthermore there is no clear vehicle-hierarchy created that results in some duplication and duplicative tests (not necessary bad).
Still it would be a big win to clear this up and remove the too unflexible FlagEncoders.
Yes. I would still define a “profile” more like a Weighting that calculates the correct (potentially time-dependent) weight per edge and uses EncodedValues. This “profile” is then also used instead of the FlagEncoder for all EdgeFilter tasks like for location snapping. The task of handling the “cached EncodedValues” (accessEnc, averageSpeedEnc) would be also required to be done, i.e. feeding these EncodedValues on import time and using them at query time.
to create such a universal parameterized profile
It is very important to split profiles into smaller units (creating a vehicle hierarchy). The worst example is the DataFlagEncoder which is something that does too much and is at the end not very useful.
Another question: You are talking about specifying the profile per request, but doesn’t this also depend on the way the map was imported ?
Say you specify a weighting that uses some OSM tag that was not included during the map import, how should this be handled ?
If an OSM tag (i.e. EncodedValue) is not imported, you cannot use it at query time and it will give you an illegalargumentexception or something
And what about ‘external’ data that should is not included in the ‘edge properties’, but should be included for the weight calculation nonetheless (like traffic information ?).
There is no reason anymore why it shouldn’t go into an EncodedValue (except for variable length data like e.g. string names). Still having an option to define arbitrary parameters in the profile that are then used in the Weighting should be also considered. And allowing time-dependent parameters should be also in the scope of this task. Puh 