I'm renaming this method before the bad naming convention runs rampant:

getName: human readable name of Task/Perk
getDescription: human readable description of Task/Perk
getClassName: class name of Task/Perk
getIdentity: programmatic string name assigned to a Task

In keeping with these other methods, this one should be called getAnchorTaskIdent. I will fix all references (there are few at present) when working on this bug.

getAnchorTaskId() may be a better name than getAnchorTaskIdent().  It is both easier to identify it's function and is less wordy.

Agreed.

Here's what is now implemented:

getAnchorTaskId: Identity string of the task to which the one currently executing is chained, or None if this task is not part of a chain or the anchor has no string ID.

getAnchorPerkClassName: Class name of the perk containing the task returned by getAnchorTaskId.

getTaskHistory: Flattened list of all task identities that have executed before this tasks in response to the same event. Tasks without identifiers are listed as None.

getPerkHistory: Flattened list of all perk class names associated 1-to-1 with the names from getTaskHistory.

getHistory: Results from the two methods above combined as pairs in a zipped list. 

The identity parameter is now required on all Tasks. It may still be set to None, but must be done explicitly by the programmer. To clean up, I went through all the Tasks we currently register, gave important ones identifiers, gave other ones None as an id, and made all the names follow a standard convention of:

<some unique prefix> <task purpose>

For instance:

read all
read all continued
firefox read document address