What makes TMX Keyword driven testing different than others?

I first learned the power of keywords 20 years ago from a test industry superstar who I will name at the end of this post.
One of the fundamental principals of keyword testing is that the keyword definitions and user interfaces are separated from the automation execution engine. Early successes used simple spreadsheets and macros to generate executable code. It was in the late 1990s when I designed the 1st version of TMX based on the idea that the testers needed a tool that define tests more formally than just narrative but less technical than automation code. I needed a separate abstraction layer that was designed for and easily usable by testers but could generate code (or not).
Most automation tools (UFT, Test Complete, Rational Functional Tester, Selenium, Visual Studio, etc.) have keyword capabilities; all of which are specific to their automation technology stack and licensing. While this is a good thing there are some issues.

Defined by the needs of the tester

Testers need to design, document, maintain and organize test cases that can easily be shared by a team. They need to be able to define keywords at the right level of granularity, using the language natural to their environment. They also may need a different library of keywords for different testing projects. TMX uses a shared database and a UI specifically designed for non-engineer users.

Licensing is more manageable

The number of test designers will be different than the number of automation engineers on a project and they may be in different locations. The test project may be using more than one automation tool (Selenium, Appium) for different parts of the testing or no tool at all. It makes sense to license and install the test design tool separately from the automation tool since designing and maintaining tests is a separate role than running the scripts and often done by different people.

Prevents vendor-lock

One of the biggest advantages of separating test design from the executable code is being able to change what code is generated but not having to change the keywords or the test cases. It is nearly irrelevant to the test designer whether the executable code is Java for Selenium or C# for Ranorex or was UFT but now is a newer tool. It also may be required to execute parts test scenarios with code for different automation tools. If the keyword interface you are using is integrated with a specific tool, it can be very difficult to switch tools in the future.

The problem of re-authoring test cases by engineers​

One of the biggest challenges of automating tests is the translation of a test case design to an automated script. A subject matter expert (SME) may design test cases at a certain level that makes sense to her but the translation to code by an engineer requires the engineer to fill in all the implied detail and domain knowledge for automation. Essentially the engineer is re-authoring each test into code that the original designer will have difficulty understanding because it requires understanding the code. I will expand on this problem and solution in a future BLOG.