What does MQL5 ObjectGetInteger(0, ObjectName(0, i, 0, -1), OBJPROP_TYPE) give us?

I think the type of an object with an index i must be found by the following code:

ObjectGetInteger(0, ObjectName(0, i, 0, -1), OBJPROP_TYPE)

But this does not give me the index. The above code gives a number, and this number is different from the order of ID#s in the table of ENUM_OBJECT. For example, it gives 12 for OBJ_FIBO but 0 for OBJ_VLINE.

From the two available ObjectGetInteger()-function's calling signatures, your code uses the value-returning one :

long  ObjectGetInteger(  0,               // chart_id, = an MT5 chart identifier
                         ObjectName(      // name,     = an MT5 chart object name string,
                                          // (           served by an ObjectName()
                                       0,    // chart_id,
                                       i,    // pos,     Obj's in-chart ordinal number 
                                       0,    // sub_window {-1 = all | 0 = main | n }
                                      -1     // type       {-1 = any | ENUM_OBJECT }
                                      ),  // )
                         OBJPROP_TYPE,    // prop_id,  = ENUM_OBJECT_PROPERTY_INTEGER
                         0                // prop_modifier ( default = 0, Fibo-level or pitchfork ordinal )
                        );

So far so good.

Your code serves a value for each i-indirectly addressed ( most probably iterated ) GUI-object.

The rest is interpretation. ENUM-s, used as #def-ed symbols, are symbolic proxies for actual values ( AMQP + ZeroMQ father, Pieter HINTJENS, calls them "HAUSNUMERO"-s, using them like :
#define PUBLISHED_ENUM_CODE HAUSNUMERO+36791
which underlines the separation of actual value from symbolic definition, many times preventing (un)intentional collisions if some guessed value was used in function call, so as NOT to reference a given #def-ed property. A weak, but ultimately better than none, protection from run-time hard-to-debug crashes. )

If in a need, create a trivial, yet robust, ENUM-decoder :

switch( aReturnedObjPropEnumVALUE )
      { case OBJ_VLINE:           Print( "This one was an OBJ_VLINE" ); break;
        case OBJ_HLINE:           Print( "This one was an OBJ_HLINE" ); break;
        case OBJ_TREND:           Print( "This one was an OBJ_TREND" ); break;
        case OBJ_TRENDBYANGLE:    ...
        case OBJ_CYCLES:          ...
        case OBJ_ARROWED_LINE:    ...
        case ...                  ...
        case OBJ_GANNGRID:        ...
        case OBJ_RECTANGLE_LABEL: ...
        default:                  Print( "This was a VALUE not seen in .h or #def-s during MT5 compilation" )
    }

If for nothing else but curriosity, one may drill another level deep and reverse-engineer the current ( version dependent, closed source code defined, sure ) value of any ENUM-symbol :

int aHASUNUMERO_deCODE_if_ULONG( ulong aGuessedToBeIntENUM_to_decode ) {
    ulong  aDumbForceINT = 0; while (  aGuessedToBeIntENUM_to_decode != aDumbForceINT ) { aDumbForceINT++ } 
    return aDumbForceINT;
}

It is obvious similar approaches are weak and inefficient, as a mere case of a single string, used among other closed-source #def-ed ENUM-values, will turn all similarly naiive efforts in wreck havoc.

Anyway, enjoy the day - C'est La Vie