The elbowtee is both an elbow and a tee simultaneously, or alternatingly. You wouldn't call it a teeelbow because that's too many E's in a row to even read correctly. I already digress to semantics and linguistics. A forum search did result that no one has used the word elbowtee here before this post.
I have been producing stable piping assemblies and subassemblies after some experience creating unstable ones, and even implemented a limited modular multi-SSP method. Increasingly, I have adapted to linear patterns while applying exceptions by envelope status. Any pipe header that crosses the pattern adjoined gets a Tee to start with. Regardless of whether it outlets to an external flange(s), or terminates across it at its ends, something in the middle will have a tee. The tee is in the pattern. Where a tee is not needed, I later select those and make them Envelope status (and eventually will need to hide them before saving as 3d pdf). Then I mate an elbow's axes upon the tee's axes where applicable. The tee where it is not needed works as a placeholder. Naturally, I can hide envelope items in the drawings generated from the assembly, and envelope items do not contribute to mass, center of gravity, or bill of materials.
I have relevant 3D Sketches in each part, upon which relations (but not lasting mates) are defined, primarily for derived virtual weldments. Because of coexistence by envelope, either part can be mated and related upon and will retain its binds. This is the driving purpose of retaining the wrong part. Other things are already defined upon it. We have revisions to implement. Keep it and proceed.
This is my secret of envelope status as much more than just someone else's stuff that you're attaching to, as it was introduced to me in sheet metal lessons context. I'm considering expanding it into the elbowtee that works in all cases where a common Front Plane is the common anti-axis parallel mate.
Today, I quickly reiterated a 2-thing system (no middle tees, but exception tees) into a 4-thing system. Other things adapted. It was things working well from an original intention well defined. I didn't even utilize SSP method which handles this intuitively, and I did perform some applicable copy with mates, mirror bodies, and even a desperate face move to alter a well-developed weldment body without blowing up its chained group.
I can do better.
I've developed the tee that I use to contain consistent orientation upon axes, and consistent naming schemes for every reference entity I'd need in any variation across similar item types, more applicably than Routing does (yeah, have that and won't rely on it). Tees have their primary, secondary, and branch definitions of seats, faces, and axes. Elbows have primary and secondary similarly. In ideal uses, primary is upstream and secondary is downstream, but you know that what works fast works well enough. Mates upon useful reference entities are flippable anyway.
But if I had one subassembly containing only those two semi-interchangeable items, in alternating envelope status per superconfig that would necessarily duplicate all available component configurations (rating, size, material, connection), I could always use that and switch it out interchangeably on the fly. It would already carry its alternative along with it. But, how many alternatives would I need?
Does anyone else have experience making a dual purpose component in this manner?
* Do I need a 3rd situation with primary axis flipped to make an elbow at both ends and still adapt? (yes?)
* Do I need a 4th situation with tee branched opposite as well? This is getting complicated.
* Complicated isn't complicated enough yet. Now if I had secondary potential orientations of tees, would I also have quaternary potential orientations of elbows? Multiply variation upon variation, and how many subconfigurations do I need?
* And how do I order subconfigurations usefully, navigably? This is where prior experience would help most. At worst, I'd make something that doesn't work well and want to remake it.
* A Cross or 45 degree elbows in there. Aw, hell no. Exceptional can stay an exception.
* I can still envelope the whole subassembly, right, and that makes all its components envelope? Put something else on that and maintain (some) existing relations. Anything can happen.