Copied from https://www.mediawiki.org/wiki/Topic:Vxpl2cp04t2yymbt:

Note that in a relatively fresh install of MW 1.35 / VE, attempts to edit Templates using TemplateData information results in [https://imgur.com/a/q9kla6J this] kind of poorly formed reference to the Template in question, forcing one back to source code editing. After some digging, it turns out that $wgArticlePath *must* be set to something (e.g. "/$1") other than the default, otherwise javascript code in the VE extension (specifically, mw.libs.ve.decodeURIComponentIntoArticleTitle in modules/ve-mw/preinit/ve.utils.parsoid.js) will not properly extract the title (Template:Cite Book in the example) from the default index.php?... URI.

Sure, here are (VM, so passwords unsanitized) NGINX and LocalSettings configs for MW1.35 in a state where the issue should be occurring:
https://pastebin.com/0SsiJpje
https://pastebin.com/bqvX6tZT
Unsure about what's going on with that strange capitalization, my guess is higher-level formatting based on the incorrect assumption that it's a page name and therefore should be capitalized (doesn't really explain the initial ":", though). Since changing $wgArticlePath fixed the issue for me, I suspect those are superficial formatting problems thanks to bad input. My suspicion about decodeURIComponentIntoArticleTitle stems from the fact that it really does nothing of the sort, it simply de-escapes the URI without performing any extraction of the actual ArticleTitle (from the URI) at all, which is precisely what is observed from the front-end. Specifically the following chain of events seem to occur:

1. the href referring to the clicked-on template is passed to normalizeParsoidResourceName

ve.dm.MWTemplateModel = function VeDmMWTemplateModel( transclusion, target ) {
       // Parent constructor
       ve.dm.MWTemplateModel.super.call( this, transclusion );
       // Properties
   this.target = target;
   for	(var i in target)
   {
console.log("BJS "+i+" "+target[i]);
   }
       // TODO: Either here or in uses of this constructor we need to validate the title
       this.title = target.href ? mw.libs.ve.normalizeParsoidResourceName( target.href ) : null;   /// BJS ********* href ./index.php%3Ftitle=Template:Book
       this.sequence = null;
       this.params = {};
       this.spec = new ve.dm.MWTemplateSpecModel( this );
   this.originalData = null;
};

2. normalizeParsoidResourceName is essentially a wrapper to parseParsoidResourceName, which in turn passes the decoded URI to decodeURIComponentIntoArticleTitle

mw.libs.ve.normalizeParsoidResourceName = function ( resourceName ) {
        return mw.libs.ve.parseParsoidResourceName( resourceName ).title;
};
mw.libs.ve.parseParsoidResourceName = function ( resourceName ) {
        // Resource names are always prefixed with './' to prevent the MediaWiki namespace from being
        // interpreted as a URL protocol, consider e.g. 'href="./File:Foo.png"'.
        // (We accept input without the prefix, so this can also take plain page titles.)
    var matches = resourceName.match( /^(\.\/|)(.*)$/ );
    console.log("BJS utils.parsoid matches "+matches);
    console.log("BJS utils.parsoid matches decoded "+mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ));
        return {
                // '%' and '?' are valid in page titles, but normally URI-encoded. This also changes underscores
                // to spaces.
                title: mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ),
                rawTitle: matches[ 2 ]
        };
};

3. However, and I believe this is where things go horribly awry, decodeURIComponentIntoArticleTitle does nothing of the sort, it simply runs decodeURIComponent against the string, without extracting the article title (which is presumably what is intended per the function name) - so everything that subsequently uses template.title is in fact still using the URI, not the article name.

mw.libs.ve.decodeURIComponentIntoArticleTitle = function ( s, preserveUnderscores ) {
        try {
            s = decodeURIComponent( s );
        } catch ( e ) {
            console.log("BJS error");
            return s;
        }
        if ( preserveUnderscores ) {
                return s;
        }
        return s.replace( /_/g, ' ' );
};

TL;DR: It appears like there is code that feeds arbitrary href attributes like href="/index.php?title=Template:Foo" into code that is unable to understand anything but href="./Template:Foo".