***** "Classic" B&B *****

For each of the core map data types (points, lines, sides, polys) you have a
second array of "inserts".  These function to hold the re-added sections in each
one.  Each insert has an (integer) element which is the index of the next insert
of that type for the object it applies to or NONE if it is the last one.
Points and inserts hold simply a top and bottom.
Side inserts have a top and bottom height, and also texture and light
information.
Polygon inserts have a top and bottom height and texture and light information
for each.

The map data is also modified as follows:
Points, lines, sides and polygons get a new (integer) element which is the index
of the first insert in that object or NONE.

The player motion and collision functions are modified to use the highest floor
and lowest ceiling around the player's center.  The rasterizer is modified to
draw polygon insert's tops and bottoms and side inserts in the appropriate
places.


Moving inserts are accomplished by the use of "attachables" and "attachments". 
Liquids and platforms are made subclasses of 'attachable', which has an API to
add an attachment.  All the insert types are given their own attachment
subclass.  To attach an insert to an object a new object of the appropriate
attachment subclass is created and it's variables assigned to point to the
insert, it is then passed through the API of the desired attachment.


***** "Modern" B&B *****

Sides are replaced entirely with "wall segments" which have the ability to have
their top and bottom edges be diagonal (for shadow and fancy texture effects,
this is TRIVIAL to implement in rasterization).

The classic polygon and line are slimmed down to simply vertex and line/polygon
links, and an index into the polygon/line space array.  It also has accessors to
get the floor/ceiling around a given height.

Polygon/line inserts are replaced with polygon/line spaces, containing a top and
bottom height/texture/light, and now represent negative space.  They have arrays
of the polygon and line space(s) on each side of them.

In vising, nodes are generated for each polygon space visible, and then sorted
using the old-style polygon data.  My new vis code is set up to handle this with
minimal modifications.

Also in partially in my new vis code (but untested) is support for portals,
'cause who doesn't like some good non-Cartesian map geometry every once in a
while? :)

If you have any additional questions about how any of this would work (but not
about why I'm not doing it myself), feel free to email me.