Using the "phantom interfaces" I don't actually send the traffic with VLAN tags. It's a total kludge, and I'd never recommend anybody try this at home -- but I figured out that I could make it work and trick Junos into doing things that I'd consider slightly more sane than the way Junos operates sometimes (*ONE* loopback? Come on, Juniper! 
)
The vlan tags on the phantom interfaces are just there as placeholders. Hold onto your hat for this one, you might start to think I've completely lost it.
Here's an example that's actually in production right now:
reth0 {
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
}
unit 18 {
vlan-id 666;
family inet {
address X.Y.18.145/27;
}
}
unit 420 {
vlan-id 420;
family inet {
address 10.255.4.2/30;
}
}
}The reason this works is that the router/switch upstream from this SRX does not have VLAN tag 666 configured (and even if it does, it's not applied to the interface that connects to my SRX). Since there is no VLAN 666 on the remote end, the router/switch upstream does not see a Layer 2 adjacency to my SRX on that VLAN, which means there is no "connected" or "direct" route installed in the routing table for either the switch nor the SRX. Since there's no L2 connection, the SRX won't send the traffic as a layer 2 frame, it will send it as a routed packet through the system's routing table. I add the phantom interface into our OSPF area so that the route for X.Y.18.145/27 is advertised through our network, and our upstream devices see the next hop as 10.255.4.2 (the reth0.420 interface which peers with the upstream device). The same could be done with static routes and/or redistribution.
Now, the only thing I haven't tried yet is to put multiple interfaces in the same address space, however I don't get any errors on a "commit check" if I do this, for example:
reth0 {
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
}
unit 18 {
vlan-id 666;
family inet {
address X.Y.18.145/27;
}
}
unit 188 {
description "LET'S TRY THIS!!"
vlan-id 667;
family inet {
address X.Y.18.148/27;
}
}
unit 420 {
vlan-id 420;
family inet {
address 10.255.4.2/30;
}
}
}If you're using the same address space/subnet across your "real" and "phantom" interfaces, you wouldn't even need to worry about routing voodoo at that point, since traffic is going to route back to your device for that subnet anyway. I would be cautious though that additional units/addresses in the same subnet might try to be sent as layer 2 frames with incorrect VLAN tags since they'll have direct/connected routes in the routing table.