If a keyword accepts embedded arguments and uses a custom regexp, the regexp is not validated if the argument is passed as a variable. For example, the keyword in the example below requires the argument to be a number, but the last example test that passes a string via a variable still succeeds.

*** Variables ***
${var}          bad

*** Test Cases ***
Succeeds as it should
    Example 123

Fails as it should
    Example bad

Succeeds but probably shouldn't
    Example ${var}

*** Keywords ***
Example ${arg:\d+}
    Log to console    ${arg}

The plan was to change this already in RF 5.1 (#4069) but due to backwards incompatibility problems explained in #4069 (comment) changes were reverted. New issue (#4454) was submitted about enhancing conflict resolution the problematic regexps explained in the aforementioned comment wouldn't be needed.

Improved conflict resolution works well and will be part of RF 5.1, but it is still not safe to make custom regexp validation more strict. It will, however, be deprecated and functionality will be changed later. In RF 5.1 there are no visible deprecation messages yet, but this will be documented in the release notes and in the User Guide. We'll probably deprecate it more loudly in RF 5.2 and change functionality in RF 6.0.