A registered helper hides a property named the same as the helper. Therefore, it is difficult to access a property that has a name colliding with an already defined helper (think of "if" or "each").

Accessing the property via a path is possible, but not obvious since the "./" is rejected in the lex definitions by:

"."/[} ]                     { return 'ID'; }

Therefore, a weird syntax allows reaching the property directly: "./ ".

Example:

Handlebars.registerHelper('loc',function(){
    return 'loc helper';
});

var obj = {
    loc: 'location'
};

function test(template, a) {
    var compiledTemplate = Handlebars.compile(template);
    var output = compiledTemplate(a);
    console.log(output);
};

test('{{loc}}', obj); // => 'loc helper'
test('{{#loc}}{{/loc}}', obj); // => 'loc helper'
test('{{. /loc}}', obj); // => 'location'
test('{{./loc}}', obj); // => Error: Expecting 'DATA', 'ID', got 'SEP' 

Even though this work around allows accessing the property, I do not believe it should be valid since the space between './' and the property name leads one to think that there are two parameters, not one. This is possible because of the lex definition:

\s+                          { /*ignore whitespace*/ }

This rule should probably return a white space token (WS) and let the parser handle when it is valid, or not. However, this would be a lot of work to rewrite almost the entire parser file.

At minimum, I believe that the rule relating to '.' should be modified as follows:

"."/[}/ ]                     { return 'ID'; }