Keywords in test case files with dots in name do not have precedence over imported keywords

I created resource res.robot like below:

*** Keywords ***
ok
	Log	This is external res.ok
res.keyword
	Log	This is external res.res.keyword

Then I created test suite Test.robot, which inside has keywords res.res.keyword and res.ok like below:

*** Settings ***
Resource	res.robot

*** Test Cases ***
Test Check
	res.ok
	res.res.keyword
	
*** Keywords ***
res.ok
	Log	This is internal res.ok
res.res.keyword
	Log	This is internall res.res.keyword

According to documentation http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#handling-keywords-with-same-names 1. Created as a user keyword in the same file where it is used. These keywords have the highest priority and they are always used, even if there are other keywords with the same name elsewhere.

What I see in the output is that RF call resource file keywords instead of corresponding internal, so I got message from res.robot file:

20161118 09:32:03.353 : INFO : This is external res.ok
20161118 09:32:03.355 : INFO : This is external res.res.keyword

Is it expected behaviour or a new issue?

[pekkaklarck]

Scrap that! We can fix the original problem by always first looking does the test case file have the specified keyword. This can be done regardless does the keyword name have dot or not. If the test case file doesn’t have such keyword, we can then first look from resources/libraries if the keyword has a dot. This implementation ought to cause no backwards compatibility problems and ought to also be in sync with the documentation.

[pekkaklarck]

After implementing the change, our own tests showed that it can break tests using embedded arguments. For example, if we have keyword like ${embedded} args in a resource file and use it like resource.Embedded args, variable ${embedded} nowadays gets value Embedded but after the change it would get resource.Embedded. This would be too big change in a minor version, and I’m not sure would that really make sense even in a major version. I guess the current implementation is actually the best one. We just need to document it better.