When working with NBTs in commands, what data type is assumed when values don't have a letter suffix?

Solution 1:

When entering NBT, the provided data type mostly doesn't matter. It gets converted to the correct type for that field automatically.

Regular numbers become ints, so entering e.g. 3000000000 results in the value overflowing and becoming negative, even if it then gets converted to a long.

Numbers with decimal points become doubles, including .0 and 0..

Just a . seems to be accepted as a number, but I wasn't able to figure out what type. It plays along with other numbers labeled "i", but that shouldn't be a number suffix. Strange.

In arrays (like Motion) only one number type is accepted, even if they are compatible for conversion. So [1.0,2.,3d] is accepted, but [0.0,0.0,0.0f] is not.

Apparently arrays don't convert from whole number types to floating point types. Summoning an entity with Motion:[1,0,0] does not give it motion.

The remaining types are trivial: Array, compound and string. They don't have type suffixes.

Now to the other side of things: When reading NBT, you do have to match the correct type. Because your input gets implicitly converted to int or double if you provide no format suffix and only then it's compared with the existing NBT, it often fails.
So even if you summon an entity with Motion[0.0f,0.0f,0.0f], you still can't test for it with Motion[0.0f,0.0f,0.0f], you need Motion[0.0d,0.0d,0.0d].