> > - Allow more/all things inside Elements, on explicit layers.
>
> This one in particular is not a small incremental step but a fairly > drastic change.=C2=A0 A lot of work is likely to be required to fix al= l the
> points that make assumptions about Elements.=C2=A0 I'm not saying = it's a
> bad idea, but it's hard.

Yeah, hard :-)=C2=A0 Internals-wise, the problems are many-fold:

If it were easy, anyone could do it! := )

=C2=A0

* The GUI needs a way of letting the user specify a BBvia
* The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)
* The GUI needs a way to let the user specify which layer pairs may have BB= Vias

These are solvable problems that a= re for the UI to work, and shouldn't affect the design of the underlyin= g data structures (opinion).

=C2=A0

* The exporters need to know how to export a BBVia (esp drill files)

Exporting a BBVia is as simple as exporting a= ny other through hole pad. The drill file is the trick. That's why I su= ggested being able to create a drill layer that is could associated with a = particular layer. Then the fab could use it to know which layers to drill f= or the buried components prior to lamination.
=C2=A0
* DRC needs BBVia-specific rules

This d= epends on how DRC looks at the BBVia. If DRC just sees them as pieces of co= pper, then it can those pieces and look for overlaps, or however the regula= r DRC works.

* DRC needs to know where BBVias connect to

I wouldn't think (perhaps naively) that this problem is unique to BBVi= as.

* Find, likewise
* Report, likewise
* auto-drc needs to know when to let you go "past" a BBVia
* ...which implies a real physical stackup is needed, and enforced

If the auto DRC is just checking connectivity a= nd spacing, then if you route a trace on a layer that the via doesn't i= ntersect (have a pad on), it shouldn't actually notice it. A layer orde= ring is necessary certainly, but it doesn't have to be a real physical = stackup. And the layer ordering is really only important when the BBVia is = placed because that's when it creates the primitives on particular laye= rs. I don't think that the DRC should really care much what kind of com= ponent placed the primitive where it is, it should just care whether the pr= imitive is too close or overlapping with another primitive (clearly this is= opinion, and there are probably lots of cases I haven't thought about)= .
=C2=A0
* ...which implies more GUI changes
* will autoroute use BBVias?

It could i= f you teach it to, but there's no reason it has to. The autorouter does= n't need to use every tool in the tool box. The interface should allow = it to if it's smart enough, but I would suggest worrying about the auto= router down the road. What we've been discussing here is at a much lowe= r level.
=C2=A0
* what about the optimizers?
* We need a way of storing BBVias in a file
* ...and storing them internally

I thin= k that if the component model becomes a collection of primitives, then they= would be stored just like components, or other vias. Primitives on particu= lar layers. I know someone has disagreed with me about vias or BBVias being= essentially simple components, but I don't understand that argument. P= erhaps someone could explain it to me?
=C2=A0
* ...and hooking them up to all the object-oriented code throughout
* ...and hooking them up to the rtrees
* ...and teaching rtrees how to find only BBVias that intersect the layers = in question
* ...and define "layers in question" accordingly
* etc

=C2=A0

So let's call this a "drastic incremental change" - it's = doable in the
context of the current code set but it's a lot of work.

But enough talk.=C2=A0 Who's going to do all that work?