First off, it’s clear that the metaphor the writers initially had in mind was a computer storing data. The TNG tech manual is just vague enough to be ambiguous on this point, but very heavily implies a “scan and save a pattern -> destroy the original -> rebuild from the pattern” process. Terminology like “pattern buffer” no doubt comes out of that conception.

It’s also clear that by the end of 90s Trek at least some people with decision making power felt it was really important to explicitly shoot down a lot of the “kill and clone machine” theories about how transporters work, which is why Enterprise in particular is full of counter-evidence. Of course, TNG Realm of Fear was clearly not written by someone with “kill and clone” in mind, and stands as another very strong bit of evidence against that theory. The conflicting intentions make things confusing, but they are not irreconcilable.

My preferred explanation is as follows: When they shift something into subspace, they still need to keep an accurate track of exactly where in subspace everything is (the “pattern”), in addition to preventing whatever extradimensional subspace interference whosamawhatsit from damaging the matter itself. (If you’re familiar with computer programming, the pattern is functionally a huge set of “pointers”, not pointing to a specific piece of computer memory, but a specific point within the non-euclidian topology of subspace.) This pattern is stored in the “pattern buffer”, a computer memory storage unit with an extremely high capacity but which only retains data for a limited time. The transporter then uses this pattern to find the dematerialized transportee in subspace and rematerialize them at the target coordinates, taking great care to ensure that all these trillions of pieces are moved to the correct locations in realspace. These steps can be (and often are) accelerated, with a person beginning to materialize at the target coordinates while still dematerializing on the transporter pad (see TNG Darmok for an example off the top of my head).

The reason you can’t just tell the transporter to make another copy of what’s in the buffer is that although you have a lot of information about whatever you just dematerialized, you only have one copy of the matter in the buffer. If you try to materialize another one you’ll be trying to pull matter from subspace where none exists: the transporter equivalent of a Segmentation Fault, to use another computer science term. If you tried to use that pattern to convert an appropriate quantity of base matter into a copy of whatever was in the buffer, you’ll still be missing any information about the transported material which can’t be gleamed exclusively from a mapping of where each piece was: you won’t necessarily know exactly what every piece was, at a precision necessary to recreate it. Especially if the diffusion of material into subspace is sufficiently predictable that the pattern doesn’t need a pointer for every individual subatomic particle, but can capture a a cluster of particles with each one.

We know from the existence of “transporter traces” that the transport process does leave behind some persistent information about a person who was transported. We also know that it is possible for the transporter operator to identify and deactivate weapons mid-transport. It makes sense that a mapping of pointers could be extrapolated out to get a lot of data about the matter being transported (such as detailed information on a subject’s cellular makeup, or if there’s a device capable of discharging a dangerous amount of energy) while still falling far short of the data required to make an exact copy.