What I hope for from data structure support

creating a new type of object should be SIMPLE:
  a SINGLE source file for a data structure which can generate code for
    access 
    print dump
    Output
    Input
    debugger knowledge of my data structure, or at least access to that
        knowledge from inside debugger
    browsing of files, and data structure in memory
    ntupling
    graphical display?

SIMPLE coding, and less/easier debugging:
  access to data SIMPLER than from raw ZEBRA

a means to that would be compiler support of:
    access via names of objects and elements thereof
        in code
        in debugger
    detection/prevention of dangling/null pointers
    ?forbid writing into a dangling pointer?
    bounds checking
    type checking
    detection/prevention of memory leaks, at LEAST by casual user
        (memory leak = useless allocated memory, growing with time)
--------------------------------------------------

Nasty problems:

    Can I support the PATH notion?  Do I need it?

    Can I dynamically create a structure as complex as an event 
        - with variable numbers of hits, and sometime missing substructures
        (electrons, say)

    need analogs to dropping of structures before writing?

    How do I read in old data with a previous VERSION of this data structure
        (assume I make a rule to only ADD items to a structure?)

    How self-describing is the data format?
        Zebra: type info encoded
               pointers supported
                    structural pointers = implementation of substructures
               names of objects (banks) but NOT elements of objects
               -  enough to read it back in and interpret later (version #'s)

    EZ replacement: give hierarchial name in every call?
        "bank.var" instead of "bank"