In UrlAliasService, both lookup($path) and reverseLookup(Location $location) return UrlAlias object. This object contains $isHistory property, indicating if the UrlAlias object represents a history path or not.

When reverseLookup(Location $location) is used, returned UrlAlias object will never be history, since the method only returns active autogenerated and custom aliases.

When lookup($path) is used, history state of the UrlAlias object depends on the path. Since path is stored in parts, for example for path /one/two, one and two are stored separately and ID is defined on each stored part, $isHistory will not be unambiguous for the same ID, but will depend on the $path argument. Example, we have stored URL aliases:

• /one (ID:1, history: false)
• /one/two (ID:2, history: false)
• /one-old (ID:3, history: true)
• /one/two-old (ID:4, history: true)

These paths will have same ID, but different history state:

• /one/two (ID:2, history: false)
• /one-old/two (ID:2, history: true)

Additionally, $pathData property in the SPI UrlAlias object will depend on the $path argument, since UrlAliasService needs to check if the path is loadable for the given language configuration.

This can be solved by introducing new API value object UrlInfo, which would be returned by lookup($path). With it, API UrlAlias object ID becomes unique and the $isHistory property can be removed from it. Also, $pathData property on SPI UrlAlias object becomes unique as well.

This will simplify caching in both SPI and API (future) layer.

Example of the UrlInfo object can be found here: https://gist.github.com/pspanja/3781309