While the PSR-800's data architecture is nothing like the PSR-500/600, a talkgroup can still belong to exactly one trunked system.
Why would you want to put it in more than one?
For those multisite systems wherein each site shares common talk groups. As it is now (with my 500) I must create a "common" TSYS which has those talk groups or else I would have to duplicate them across the other location specific TSYS's.
I recall this being a sort of "hot topic" amongst some users monitoring very large systems shortly after the 500 came out - predating my owning of one by quite some time - so the question/desired feature was not originated by me. I read up on it and knew about it before I even purchased the scanner knowing this limitation and thinking of a workaround. I came up with the "common" TSYS as my workaround.
Some users scanning very large multisite systems want to engage/disengage TSYS objects (trunking sites) belonging to the large system as they travel in and out of the coverage areas of these sites. This you can already do; however, in programming such a system in the scanner, if the system uses many common talk groups across the whole system you either have to keep programming those same talk groups in each TSYS or else you create one large TSYS containing all system-wide control channels with just those common talk groups. For me, this works, but for systems larger than the one I monitor (San Diego County RCS, which is fairly large in and of itself) such as some statewide systems I have read about creating such a common TSYS may not be possible unless you divide it up into more than one due to the additional control channels (I have only read that this is a problem and not verified it).
It just seems far more efficient to me to allow multi-site systems to reference multiple talk groups rather than force the user to duplicate such talk groups repeatedly. If I could do this (reference a talk group to multiple TSYS's), I could eliminate the "common" TSYS altogether thereby saving considerable memory space. I own one Uniden scanner with the DMA feature and can say that that is one ability that I prefer in it over the GRE OO method as used in the 500/600 scanners though, overall, I still prefer the GRE OO system (granted, maybe because I learned it first, but. anyway).
I guess I'll try and dig up the old threads concerning this discussion but it could take some time - not tonight, sorry;-) - if you want. For an example of a current need of such a feature besides myself, here is a thread I recently replied to, though it applies to EDACS systems where it is even more of an issue:
http://forums.radioreference.com/gre-scanners/201422-efficient-programming-simulcast-systems.html. Also, I could be wrong here as it has been awhile, but I seem to recall you acknowledging this as a limitation yourself when one of those old posters I mentioned asked about it - as I said, it's been awhile so I could be wrong about that but I know it was a fairly common question/requested feature for awhile after the 500 hit the market.
-Mike