If I had to guess, I suspect the core team would prefer a new engine to a new option. I suspect they would say it’s already extensible since it allows you to specify the engine, so why introduce another option.
One challenge I expect you’ll get is, why does this need to be in core? Why not in a library? José has mentioned in the past that he wants elixir to be extendable, so that everything doesn’t have to be in core.
From the tips I posted in the section pin, I think answering the following could bolster your argument:
- Will it be generally useful to a significant proportion of users? In what situations will people choose to use this engine vs the default?
- Will it substantially improve the ergonomics of an existing feature?
- How will it impact learning?
These I would considered answered as follows (assuming new engine):
- Is it something impossible or difficult to do without adding the feature? No
- Does it fit with the existing feature set? Yes
- How complex will the implementation be? Simple
- How might it impact the rest of the code base? Separate engine, so you have to opt into using it. Shouldn’t effect existing code bases.
- Does it fit with the existing goals or ethos of the project? Yes