I give up on that mysterious VAO - but here is a modified version.

First the global vars. The glCreate...() can give more than one ID, and the idea is to have more than one buffer.

/* GL objects/binds/targets 
  'VB' is vertex buffer [binding point index]
  'GVAA0' is generic vertex array attribute "0" = first 'in' of vertex shader */
int BUF[3];
int VB[16];
const int GVAA0 = 0;

The buffer setup function with "official" description in comments.

void
init_bufs_format46(void) {

    /* New Buffer, with unspecified target */
    glCreateBuffers(1, BUF);

    /* New Data Store for Buffer Object */
    glNamedBufferData(BUF[0], sizeof vertices, vertices, GL_STATIC_DRAW);

    /* fresh ID for Vertex Buffer */
    glCreateVertexArrays(1, VB);
    /* Bind a vertex buffer bind point to a buffer | Attach Buffer to Vertex Array */
    glBindVertexBuffer(VB[0], BUF[0], 0, 5*sizeof(float));                            //..., offset, stride)

    glVertexAttribFormat(GVAA0, 4, GL_FLOAT, 0, 1*sizeof(float));              // ..., reloffset)  -> skip first float 
     glEnableVertexAttribArray(GVAA0);
}

Now glCreateVertexArrays() reserves an ID. Before it was a value "3" picked at random. I hope there is no problem with VAO vs. VBO here.

The last step is now:

  /* Associate Vertex Attribute and Vertex Buffer Binding */
    glVertexAttribBinding(GVAA0, VB[0]);

better than (0, id).

VBO (Vertex Buffer Object)

This (and not VAO) is the main source of vertex data according to the 2019 specs of the "OpenGL Graphics System".

The specs themselves do not explain very much (or too much:). But this front cover is very well made.

The key to understand these historical changes in OpenGL is the "ARB Extensions Specifications". They run from #1 in 2002 to #190 in 2019; the ones I checked mostly have a useful "Overview" intro, explaining why this ARB spec was needed.

The OpenGL wiki (khronos.org) sometimes copies parts from the ARBs. The ARBs also update the specs (new functions) - no wonder the specs are so hard to read after all these additions.

ARB direct_state_acces reduces the bind-to-edit actions; it defines many new calls.

glVertexAttribFormat is from ARB vertex_attrib_binding.

Here the function in question. I put the official function description in comments. The vertex data this time is split into a position and a color part - vertically interlaced.

void
init_bufs_format46(void) {

/* ARB#164 direct_state_access, 2014 
 - New buffer objects, initialized with unspecified target 
 - New Data Store for (named) Buffer Object */
glCreateBuffers(1, BUF);
glNamedBufferData(BUF[0], sizeof vertices, vertices, GL_STATIC_DRAW); 


/* ARB#125 vertex_attrib_binding, 2012  
 - Bind a vertex buffer bind point (0-15) to a buffer   
 - Specify layout of a generic vertex attribute array  
 - Associate vertex attribute and vertex buffer binding [point] */
VB[1] = 1;
glBindVertexBuffer        (VB[1], BUF[0], 0,          3*sizeof(float));       //..., offset, stride)
glVertexAttribFormat      (GVAA0, 3,      GL_FLOAT, 0, 0);
glVertexAttribBinding     (GVAA0, VB[1]);

glEnableVertexAttribArray (GVAA0);

/* GVAA "1" is color here; same buffer but with an offset and a different stride */
VB[2] = 2;
int buf_offset = 6*3*sizeof(float);
glBindVertexBuffer        (VB[2], BUF[0], buf_offset, 4*sizeof(float));
glVertexAttribFormat      (1,     3,      GL_FLOAT, 0, 0); 
glVertexAttribBinding     (1,     VB[2]);

glEnableVertexAttribArray (1);
}

The VB(BP)s just get integers from 0 to 15. No Gen- or Create-someobj. I left the "1" in the 2nd block naked; it would be GVAA1, or then GVAA_color in this case.

(The vertex shader now has a second in, and now it just passes on both unchanged.)

float vertices[] = {
   1, 1, 0.2,
   -1,-1, 0.6,
   -1, 1, 0.5,
   //-.1,.1,.5,

   0.3, -.8, .9,
   0,   0.9, .1,    /* z=0.1 --> near tip of second triangle */
   -.5, -.8, .8,
//};
//float colors[] = {
    .8, .6, .1,.2,
    .6, .5, .1,.2,
    .9, .3, .1,.2,

    .1, .9, .6,.1,
    .7, .6, .7,.1,
    .3, .7, .9,.1,
};

ARB #28 vertex_buffer_object (2003) is also interesting:

What should this extension be called?

    RESOLVED: By unanimous consent among the working group members,
    the name was chosen to be "ARB_vertex_buffer_object".  A large
    number of other names were considered throughout the lifetime of
    the proposal, especially "vertex_array_object" (originally),
    "buffer_object" (later on), and "memory_object" (near the end),
    but the name "vertex_buffer_object" was ultimately chosen.

And vertex_array_object became #54. (A container object).

They probably think: with a front cover like that on the specification, explanations are not necessary.