Just a quick reply because I’m so hyped about the latest config changes.
You can now define a lot more with profiles, make complex combinations, and the profiles can be named as you like. e.g.:
ors:
engine:
profile_default:
service:
maximum_distance: 999999
build:
source_file: ./osm_file.pbf
profiles:
driving-car:
enabled: true
another-car:
build:
source_file: ./another_osm_file.pbf
enabled: true
encoder_name: driving-car
Everything in profile_default applies to all other entries under profiles unless overwritten there. Every profile can have its own source_file (etc.) when encoder_name is present. Also, parameters are now “logically” split into build and service related things. build only relevant for building graphs that can be omitted when just loading an existing one.
Additionally, the way you call your entry in profiles defines how it can be accessed via the API. The above examples would relate to /ors/v2/directions/driving-car and /ors/v2/directions/another-car.
And all this can be configured as well 
% with ENV and properties (no YAML file required anymore):
ors.engine.profile_default.build.source_file=./osm_file.pbf
ors.engine.profiles.driving-car.enabled=true
and
ORS_ENGINE_PROFILE_DEFAULT_BUILD_SOURCE_FILE=./osm_file.pbf
ORS_ENGINE_PROFILES_DRIVING_CAR_ENABLED=true
Btw. the above two - line examples are everything you need to run ors from now on. Internal defaults make sure you have defaults we think make most sense, but you are free to overwrite any time.
So much more. I’ll stop for now 