If we add RETURN, then we should deprecate and remove the [Return] setting. Probably should wait at least until RF 5.1 before we emit an actual deprecation warning, but documentation should be updated to mention that RETURN is the way forward. External tools like RoboCop could warn about the deprecated usage even earlier and RoboTidy could possibly convert from [Return] to RETURN. Robot itself could probably make it an error to use both RETURN and [Return] in one keyword.

I'm not sure what to do with Return From Keyword and its variants. I consider it more important to remove syntax that's not anymore needed than to remove keywords. In addition to that, conditional variables like Return From Keyword If make it possible to create shorter data than IF and RETURN combination. That said, it would probably be better to deprecate also all these to have only one way to return in the end. BuiltIn having less keywords wouldn't hurt either.

A common use case when returning is to execute a lower level keyword and returning its return value. Because we cannot separate

RETURN    value    # Return this value

from

RETURN    Keyword    # Run this keyword and return its result

I think its better to just support returning values. If you need to run a keyword and return its return value, it needs to be done separately:

${result} =    Keyword    # Run this keyword
RETURN    ${result}       # and return its result

The underlying issue here is that same that it would sometimes be nice to pass keyword return values directly as argument, but we cannot really separate

Keyword    argument    # Pass this argument to the keyword

from

Keyword    Another Keyword    # Run this keyword and pass its return value as argument

either. We already have #3187 about adding some inline keyword call syntax and it should naturally work with RETURN as well.

This enhancement requires changes on many places starting from the parser and continuing to the execution side. I explain here briefly what's needed on the parsing side and can write separate comment later about changes on the execution side. This information hopefully helps someone interested to contribute and same instructions apply also to BREAK and CONTINUE (#4079).

All this new stuff is needed in parsing:

1. New token type in tokens.py.
2. New lexer in statementlexers.py. Logic very much the same as in e.g. EndLexer.
3. New lexer needs to be used by appropriate higher level lexers in blocklexers.py. In practice relevant block lexers need to return the new statement lexer from their lexer_classes method.
4. New parsing model object in statements.py. End statement can be used as an example.
5. These changes needed to be tested using unit testes in utest/parsing. It would be good to add some tests for the lexer in test_lexer.py, but that file is so huge it's hard to see where these new tests would fi. The whole flow can be tested with tests in test_model.py and from_params method should be tested in test_statements.py.

If we will have inline IF syntax (#4093):

• [Return] value -> RETURN value
• Return From Keyword value -> RETURN value
• Return From Keyword If condition value -> IF condition RETURN value
• Run Keyword And Return kw args -> RETURN Run Keyword kw args
• Run Keyword And Return If condition kw args -> IF condition RETURN Run Keyword kw args

The stuff on the right side looks prettier to me and is always shorter, so I would deprecate all keywords and constructions on the left side. :)

If we will have inline IF syntax (#4093):

• [Return] value -> RETURN value
• Return From Keyword value -> RETURN value
• Return From Keyword If condition value -> IF condition RETURN value
• Run Keyword And Return kw args -> RETURN Run Keyword kw args
• Run Keyword And Return If condition kw args -> IF condition RETURN Run Keyword kw args

The stuff on the right side looks prettier to me and is always shorter, so I would deprecate all keywords and constructions on the left side. :)

Note that [Return] does not return anything, it just set what variable should be returned at the end of keyword.

Agreed, [Return] and all Return ... keywords should be deprecated. In RF 5.0 that deprecation will only be a note in the docs, though, because it would be annoying to get deprecation warnings in RF 5.0 from syntax that you must use with earlier. We can then consider deprecating these loudly in RF 5.1 or later. There's no big hurry in removing them either. It would be annoying to migrate from RF 4.1 to e.g. RF 5.2 if e.g. [Return] wouldn't work at all in the latter.

I expect that RoboTidy and RoboCop can help in transition.

Yes, we will add deprecation warnings in Robocop (for 5.0) and add transformer in Robotidy for replacing all variants to RETURN

I am ok with adding RETURN, but I do not think removing [Return] should be considered. It is going to force rewrite thousands of already created resources.

I am ok with adding RETURN, but I do not think removing [Return] should be considered. It is going to force rewrite thousands of already created resources.

I already have written transformer in robotidy autoformatting tool that handles it for you (it will be released before 5.0 together with other changes for 5.0). So it should'nt be the issue

[Return] will eventually be removed but it's likely to have quite long deprecation period.

In the latest release 2.1.b1, RIDE continues to use the fixed parameter Return Value under Settings. This corresponds to the value [Return] in the text editor. Robot Framework 7.1 shows then the error messages:
The '[Return]' setting is deprecated. Use the 'RETURN' statement instead.
Is there any adjustment to this?