R1 and R2 are Level-1 devices, and R3 is a L1/L2 router in the same area. R5 and R6 are L2-only routers in the same area. R4 is a L2 router in a different area. R1 through R4 have addresses in 10.10.0.0/16, R5 and R6 have addresses in 172.16.0.0/24, and the connection between R3 and R5 is numbered out of R5's LAN.
R5 is injecting a summary route for the 172.16.0.0/24 into ISIS level-2. R3 is summarizing the 10.10.0.0/16, and leaking the 172.16.0.0/24 into L1 toward R1 and R2.
R1 and R2 see everything I expect - they see the attached bit set, and receive the summary route as leaked. R4, R5, and R6 all see expected behavior as well. However, R3 does not: for some reason it is able to advertise a summary route for 10.0.0.0/16 but does *not* inject a route for that /16 to null0 in its own table. This, to me, is very weird - I would expect to see the route (after all, R5 sees a /24 to null0 in its table), but I haven't figured out why it does not inject it.
One possibility is that it's seeing some of the component routes as L1 and others as L2 routes. Another is that this could be a bug - that router is also exhibiting weird behavior regarding PPP: for some reason it can see (and send a tunnel to) a far-end router's IP address known via PPP injection, but the route is not actually *in* the table. It's a software router, so I think I don't need to worry about weirdo-corruption of linecard FIB or anything like that, but this is a new one on me.
Interestingly, both of these properties are not keeping the thing from actually *working* so go figure - perhaps it's just cosmetic.