Content type tokens

+  $info['tokens']['node']['content-type'] = array(
+    'name' => t('Content type'),
+    'description' => t('The content type of the node.'),
+    'type' => 'content-type',
+  );

The token name "node:content-type" duplicates the context of 'node'. We don't have node:content-id, node:content-author and so on either, thus it should be just "node:type".

Then I think the actual token type name 'content-type' is problematic, because it doesn't comply with the providing module's namespace - node. Yes, we really should namespace our data types too. I know core conflicts that with 'vocabulary' and 'term' too, which is in particular odd as this is inconsistent with the entity types being 'taxonomy_term', but it's probably too late to fix that in d7. But at least, let's avoid introducing more such issues.
Thus, as type names need not be human readable, I guess it should be just "node_type".

@duplicate:
'content' duplicates the 'node' context, 'type' would just suffices here. No reason to prepend 'node' or 'content' to each token of it. E.g. we use node:author, not node:content-author.

But I see that it isn't optimal that core already implements [node:type] and returns the machine name, but still it makes sense and the user can get the human readable type name by using [node:type:name]. Also, I don't think it's optimal that it is [node:type] usually, and then suddenly if the token module is enabled, it is [node:content-type]. Let's try to avoid having too much different token-names for the same thing depending on the modules being enabled, as this helps users to remember the names.

@name-space issue:
While the issue above is about the name of the actual token, the name-space issue is about the name of the introduced data-type. As said above, data types should be properly prefixed too and I don't think they should be human readable, thus I guess we should use underscores instead of dashes. In particular we should start making use of the same data type names as in hook_entity_info(), what again means using underscores.

>The node's author. Not the node's content author.
Aehm, where's the difference? Content is often used synonymously with 'node', e.g. "content type" means "node type". Having node:node-type duplicates the node context.

>We can't suddenly switch to underscores when the core token API has already set the standard for dashes, sorry.
Where has the core token API used dashes for data-type names?

>Yes, if you use 'node type' it duplicates the context. But we're using 'content-type' currently.
? Content is synonymously used to 'node' for the term "content-type". Coming back to the (valid) content author analogy: We don't use [node:content-author] either, we use [node:author] - nor do we prefix any other node-token with 'content'. The same way we should use [node:type].

@dashes:
It's just dumb using the same type names, but going with dashes instead of underscores - have fun converting them for nothing. Though it's still better than completely different type names.