To fork or not to fork

Hey @GrahamCampbell I'm rudely pinging you, I hope you will forgive me.

We've recently switched to the clientside community implementation since the one here is no longer supported.
However we also use this implementation in our backend.

We've found some inconsistencies between the community implementation and the PHP and JS implementations here. In this case the community implementation is correct according to the spec.

My question to you is this: Would you accept PRs that fix spec compliance while breaking consistency with other libraries in this org?

I'd prefer not to fork this to the community org if we can instead maintain it here; on the other hand while you're keeping this alive, it's not being actively developed (no blame, just observation).

What would your preference be? Since we use JMESPath I'm happy to contribute in the form of a fork with the community or by making PRs here; but I'd love your opinion before I make a choice.

The specific issue we're running into is the case of an unquoted string inside a JSON literal:
```
[?abc == `def`]
```
Which is supported in this library: https://github.com/jmespath/jmespath.php/blob/master/src/Lexer.php#L432
The fix is easy of course, but we'd break consistency with the JS implementation.

The specification where this is defined lives here: https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012-raw-string-literals.md
Which is obsoleted by 12a: https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012a-raw-string-literals.md

TLDR; would you accept PRs that update this library to newer community specs or do you prefer to keep this implementation consistent with other implementations in this ORG?