Regarding graphs, I also have wondered why thy are not part of the regular suite of collections / literal syntaxes in most languages. In fact, they are really rare to even see in day to day programming, despite that most of our problems could make use of them in some way. I think part of it must come down to that you can't come up with a satisfactory way to encode graphs of data in a text-based literal. You will have to have a lot of repeating of nodes depending on how you want to express it. Take this simple graph from Wikipedia for instance https://upload.wikimedia.org/wikipedia/commons/thumb/5/5b/6n...

We could express this as an adjacency list like

    Graph{  
    1 <-> 2  
    1 <-> 5  
    2 <-> 3  
    2 <-> 5  
    3 <-> 4  
    4 <-> 5  
    4 <-> 6  
    }

So there's already a lot of repetition of the node labels, but in real life applications you would probably have actual data associated with each node (like maybe a user_id, or a name, etc, whatever the "elements" of your graph are). Actually, you would in most cases have some key that identifies the node (like user_id), and some other data associated with the node (like date of birth, locale, etc). So the above notation would force some kind of notation like:

    ("user1", (1970, USA)) <-> ("user2", (1980, UK))  
    ("user1", (1970, USA)) <-> ("user5", (1990, RU))  
    ...

So now the notation would require not only repetition of the node name, but also the data itself. This would be even more of a problem if the data was not a literal but was computed, like: ("user2", (getDateOfBirth("user2"), getLocale("user2"))

So then the way around this would be to use the programming language's own variable/identifier system, like

    var user1 = ("user1", (1970, USA))  
    var user2 = ("user2", (1980, UK))  
    var user5 = ("user5", (1990, RU))
    
    Graph{  
      user1 <-> user2,  
      user1 <-> user5,  
      ...  
    }

or perhaps some other node registration system, and then just repeat the labels

    Graph{  
      Nodes {  
        ("user1", (1970, USA)),  
        ("user2", (1980, UK)),  
        ("user5", (1990, RU)),  
        ...  
      }  
      Edges {  
        "user1" <-> "user2",  
        "user1" <-> "user5",  
        ...  
      }  
    }

So now we've avoided repeating data, but we still have to repeat nodes. In some situations, a different way of expressing a graph would also be preferable to adjacency lists (you might want an adjacency table, but in sparse graphs the list is more efficient)

but by the way, for your graph system to be generally useful, you'll have to come up with a syntax and flexibility of design that ergonomically allows graphs that vary in:

directedness: support for undirected and directed edges edge wights and data: edges could be identical or they could have weights or even keys and other attributes associated with them

graph/multigraph: can there be multiple edges between the same 2 nodes?

in statically typed languages, the data type of the "key" of the nodes, the "value" of the nodes, the "key", "value" of the edges, all have to be represented to some degree in the language's type system, so at least 4 generic parameters in a graph

So, seems that there is just a huge design space and a variety of different usecases that makes coming up with a simple solution to the general problem very difficult.