The discussion of April 2012 regarding <ptr> included Lou's "we will certainly consider these revisions" and there were a few suggestions that the Guidelines might be too focused on how <ptr> is used in marking up the Guidelines themselves.
But the issue never made it into Sourceforge. So here it is.
I stand by the position that Dan O'Donnell summarized better than I did: "ptr should not be used when the textual stream depends on ptr being resolved to a particular representation (or at all)." That is, if <ptr> is just a pointer, it should merely point. If the <ptr> can't be simply ignored without corrupting the textual stream, then (at least as currently documented) it should not be used. Maybe <ref> with a @cRef, or maybe some new element, maybe an <include> with a processing directive that could be project-specific such as "everything", "title", "figureNo." -- but <ptr> isn't right, even if that's how the Guidelines are currently marked up.
(By the way, I have seen <ptr> as a straight-up include instruction. It just pointed to external XML that was meant to be read in situ.)
Really, I think <ptr> is now just a generic wrapper for @target. "Oh, I need to point -- to signal a link, a hyperlink, an inclusion of a label, inclusion of a block of XML, whatever -- like @target does, but that's an attribute and I need an element, So I'll use <ptr>."
In the discussion thread, my suggested options appeared at http://listserv.brown.edu/archives/cgi-bin/wa?A2=TEI-L;yjB6%2Fw;201204020828240700.