I mean, this is a great example of how complex systems exhibit unpredictable, emergent behavior. You think you are doing some process X (say, printing), but it turns out that X relies on some more generic layer Y (a file utility layer) which is running a set of arbitrary filter functions that you have no idea exist. One of these filters then happens to check for some magic strings in your data. And these hardcoded strings turn out to be strings that can also occur in unrelated kinds of data...
What's the underlying issue, really? Is it that detecting file types by checking for magic strings is always a bad idea? Or is it something more basic about the architecture here, more like the leaky abstractions problem?
The problem here is that the printing pipeline uses the ‘file’ tool to detect what the data to be printed is (e.g. PostScript), but ‘file’ can only ever guess the content of a file. It is a heuristic, and as soon as you have a heuristic, you will always run into cases where it gives a wrong result (otherwise it’s not a heuristic anymore, obviously).
So, I would actually disagree with the author that it is strictly a bug in the ‘file’ utility, as there is simply no completely reliable way to determine intended file type by just looking at the content[1]. You have to transmit that information out of band, and this is why we have MIME types sent through Content-type: headers in HTTP or email headers. File extensions are another method (though also ambiguous: .TXT and .EXE are almost certain, but a .DB or .BAK can be one of many things).
CUPS is probably applying this heuristic for convenience (“send anything to your printer and it just prints!”), at the cost of correctness.
[1] A simple proof for that is the existence of “polyglots”, which in this context are source code that happens to be a valid program in two or even more different programming languages (often doing the same or similar things for sport). Were CUPS to differentiate printing based on the programming language, e.g. by applying different syntax highlighting, it would not know what language to choose, and without out of band information there hardly even is a “right” answer. In practice though you can detect a file type more reliably than ‘file’, but at much more complexity than “let’s check some magic numbers in some offsets to give the user an idea of what this might be”, and it still wouldn’t be perfect.
It still is a bug in the data for file, though. As the respective bug states, the spaces should have been escaped and so file actually misidentified everything with »Tue« in that place of the file contents as the wrong type.
https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...