I was documenting the manifest.json format of Flex recipes and I found confusing that the special variables are %BIN_DIR%, %CONF_DIR%, etc. instead of their original names %bin-dir%, %conf-dir%. The same goes for your custom variables defined in the extra section of composer.json.
Is there any good reason to do this? Otherwise, I'd recommend to keep those variables unchanged because:
bin-dir I must use instead BIN_DIR)mY-BiN-dIr we should let them do that instead of lowercasing or uppercasing it ... to avoid the problems we had in Symfony when forcing lowercase service ids)Not sure I understand the concern here. I let users change the default directory structure, but that's probably a flexibility we don't need/want. The alternative would be to hardcode the directory names.
My concern was that options are originally named bin-dir, etc.

But then we "force" the developer to use %BIN_DIR% instead of %bin-dir% ... and we need to reverse that transform in our code:

Why not always using %bin-dir% ... both the user and Symfony Flex?
I agree.
in extra I must use "web-dir" to overwrite WEB_DIR. And at first sight they are totally different names.
So better to stick to one naming.
Another thing that was weird - flex should at least write info message what's replaced value of %WEB_DIR% in info messages. I didn't understood at first that this was replaced in internal command execution process to "web".
Maybe something like one of these
Executing script assets:install --symlink --relative %WEB_DIR% ("web") [OK]
Executing script assets:install --symlink --relative web (%WEB_DIR%) [OK]
Executing script assets:install --symlink --relative web [OK] (%WEB_DIR% => web)
Closing as there is no more activity here.
Most helpful comment
My concern was that options are originally named
bin-dir, etc.But then we "force" the developer to use
%BIN_DIR%instead of%bin-dir%... and we need to reverse that transform in our code:Why not always using
%bin-dir%... both the user and Symfony Flex?