Tinderbox aliases don’t allow children. Some query methods (I don’t recall which as I write) allow testing of implied descendants, i.e. the original note’s descendants. It’s not a matter of deliberate difference but simply each app’s own design.
Tinderbox aliases always share the original’s text links. Basic links (note-to-note) are shared unless links are made to the alias itself, in which case it essentially has it’s own discrete basic links.
If interlinked notes are duplicated, the copy’s links still point to the original to the original target. Thus assume note ‘AA’ links to ‘BB’. If I select both notes and duplicate them, we get ‘AA copy’ and ‘BB copy’. But, ‘AA copy’ links to ‘BB’ and not ‘BB copy’. Depended on what you desired this may or may not be the expected outcome.
Tinderbox design draws on past hypertext systems. Hypertextually, it makes sense to have a canonical source to which aliases point, thus you only need one set of descendants as going from an alias you get to them via the descendant. IOW, context follows the links. Having everything replicated reverses this, by pulling extra content into the current context. There’s no right or wrong, they’re different approaches. I merely make the comparison to avoid the presumption that Tinderbox may be doing things the ‘wrong’ way.