With no parameters, new Map<KeyType, DataType>()
and new Map<KeyType, DataType> { }
have identical behavior. I tested a loop of 50,000 new maps of each and grabbed the timestamps from the logs, and they were almost consistently 64ms for 50,000 maps (we can't account for server load, however, so this performance may vary); approximately 0.001ms to create a new map either way.
The difference, however, is that each form has a different purpose. The parenthetical version is used to create a map from a list of SObject records or another map. They look like this:
Map<String, String> a = new Map<String, String>();
Map<String, String> b = new Map<String, String>(a);
Map<Id, SObject> c = new Map<Id, SObject>([SELECT Id,Name FROM Contact]);
The bracketed version is used to instantiate a map with values:
Map<String, String> a = new Map<String, String>{
'a' => '1',
'b' => '2',
'c' => '3' };
Force.com Platform Apex Versioning and Feature/Field Visibility
The platform (or more specifically Apex runtime) often (but not always) conditions the visibility of various features (including fields on objects) based on the API version (linked with platform version) associated with Apex code file containing the code being run. This way new features arriving on the platform don't break existing code, but it also means unless you upgrade the API version of your code it won't see new features/fields. This is driven by the -meta.xml file associated with your Apex and VF pages, also visible in the UI under Version Settings tab.
RE: Difference in behaviour in Execute Anonymous
When you run Apex code fragments this way, you have no containing Apex class or -meta.xml file. In this case the version of the Apex Web Service API being used to execute the Apex code governors the version of the Apex runtime your code runs in. I suspect your running your code in the Force.com IDE? Which likely uses a version of the Apex Web Service that pre-dates the introduction of this field (new for Summer'13). So try upgrading your Force.com IDE to resolve this. Note that if you use Developer Console to perform the same via its Execute Anonymous window, the code will work, as this is implicitly always on the latest platform version.
Resolving your Issue
Thus the first thing to check is that your using the latest API version in your code and VF files, I like to ensure they are all on the same version. The latest version, as of Summer'13 is API 28. This LastReferenced field was introduced in API 28, so use either of the two approaches to check and change your API version of your code and VF files.
Slight Oddity about your Issue
In theory the Apex Describe should return fields only supported by the API version the code making the describe calls supports. Thus you should reasonably expect to pass them to a SOQL query as well. What might be a platform bug here is the Apex Describe is surfacing the LastReferenced field incorrectly for older API Apex code, while the SOQL parser is correctly enforcing the perception that at that API level it didn't exist. Regardless updating to a new API version should resolve it, though if Apex Describe is "leaking" new fields regardless of the Apex callers API version this could reoccur. I'll do a little testing on this see if I can prove this assertion about a possible platform bug.
Best Answer
Here is what I get in my DE org with a namespace (for this example say NS):
Debug outputs as
This is in the org where I have the NS set
Check via going to:
Setup -> Create -> Packages
If you do not see CTO next to the Namespace Prefix then CTO is not local and thus localName will include CTO__