(a line count would be more involved, and the primary author of the bibtex parser I use won't be back until mid-feb. it's not something I'm going to do without consulting with him)
It is indeed the string definition that's causing this in Zotero proper. Zotero has supported string definitions from the beginning, but it looks like a change in 2014 may have broken this. (Zotero handles parentheses instead of curly braces fine, and if a string definition isn't included in the file it just uses the string definition as literal text, so neither of those is a problem here.) This is a trivial fix, but it looks like we don't support concatenation using '#' and instead silently discard the part after the '#', so we should fix that at the same time, since they're likely to be used together.
Issue created. I don't know when I'd get to this, so it'd be great if someone BibTeX-inclined was able to work on this and also create some tests in Scaffold for string definition handling and concatenation.
I've taken a quick look, but they way I'd go about it would require a lookahead at the end of getFieldValue and I had to keep passing around state -- it got more complicated than I could handle quickly.
5.0.73 is out with round-brace reference parsing and line numbers for errors. @rpgoldman , I'd appreciate it if you could see if there are remaining cases in your import BBT doesn't handle; if so, could you open an issue on https://github.com/retorquere/zotero-better-bibtex/issues ?
BBT does concatenation (by virtue of the parser I co-maintain with the fiduswriter author), and has the same behavior as the Zotero BibTeX importer -- unresolved strings will be replaced by their name.
edit: in this parser lookahead is trivial because it is not a streaming parser, it works on the whole input as one large string. For large library imports, it will use more memory than the Zotero BibTeX parser.
Although I suppose it would be doable to change that to a streaming parser with a chunked buffer, which would allow both lookahead and streaming. Hmm...
I have tested my input file, and it definitely works much better. But there are also some entries in the bib file that don't show up in the database, both with standard Zotero import and Better Bibtex. I found a bunch of bugs in the bib file (that didn't bother bibtex itself), as a side-effect of using Emacs's parse bib, and fixed them. I have created an issue on github.
BBT 5.0.74 imports these cleanly with the exception of two malformed references. These may not bother bibtex itself but neither would I expect these two to render consistently in bibtex, and moving the broken fields to the top of the reference would have them not render at all. The Zotero/BBT combo has a lot of limitations but at least it won't output broken bibtex.
Upgrade Storage
In any case, BBT 5.0.72 should import them.
Issue created. I don't know when I'd get to this, so it'd be great if someone BibTeX-inclined was able to work on this and also create some tests in Scaffold for string definition handling and concatenation.
edit: in this parser lookahead is trivial because it is not a streaming parser, it works on the whole input as one large string. For large library imports, it will use more memory than the Zotero BibTeX parser.