I don't know who needs to hear this but...
Merkle trees can be any size and shape they want.
To put a finer point on it:
"Merkle tree" does not imply "binary" nor "balanced" tree, and technical documentation should be clear when it discusses these additional properties.
It's an odd buggaboo to be hung up on, I know. But I, your humble author, hash things a lot. And this comes up sometimes: it can be a point of confusion between different communities, some of whom attach different, or simply too much meaning to a term. And I'd like to put this to rest. We can all share jargon in one big happy hashy family :)
Merkle trees are widely credited as being named for their inventor, and specifically, refering to the patents that Ralph Merkle filed.
We can find these patents though the magic of the internet: https://worldwide.espacenet.com/patent/search/family/022107098/publication/US4309569A?q=pn%3DUS4309569
(They're actually pretty fine reading. Go ahead, click the link.)
One thing is definitely clear and consistent: if we're refering to "merkle trees", we're refering to hash trees.
The original patent text couldn't be any clearer about this:
There are many methods for implementing the form of the invention. For example, the authentication tree need not be a binary tree but may be a trinary tree
The original specification uses binary trees as the example... but is in no way specific to binary trees.
The predominant attitude in discourse seems to be converging pretty resoundingly on considering any hash tree, of any shape and branching factor, is a merkle tree.
Git is certainly often enough referred to as a merkle tree. Git is not a binary nor balanced tree. That's pretty much game set and and match, in my book.
There exist communities which lade additional meanings like "balanced" into the meaning of "merkle tree"... to roughly the same degree as there are always communities, in any sufficiently large swarm of people, who assign special meaning to specific words. If you're inside one of these bubbles, it may seem like everyone presumes the same meaning you do. Nonetheless, I would hold: the predominant view in the larger community of software developers overall is clear: "merkle tree" means "hash tree", and not much else.
The question in the section header answers itself. Then the important property was "balanced" -- and it always was.
Say it.
"Merkle tree" definitely means that the hashes in the tree are meant to provide some security properties. It wouldn't be widely accepted to call something a "merkle tree" if it uses a non-cryptographic hash, in other words. (Fortunately, the meaning of the word "hash" is popularly converging to mean "cryptographic hash", as contrasted to a non-cryptographic hash increasingly being referred to as a "checksum" -- meaning this isn't very ambiguous or contentious at all any more, from multiple directions.)
That's it.
The presense of a merkle hash over a document structure also often suggests it's suitable for content-addressable storage, and thus maybe the merkle tree root hash will be useful for finding the full document in such a content-addressed storage and retreival system. However, this is true of any structure that can be hashed in any fashion; that trees are involved is not the salient detail.
No, I don't think so.
Admittedly, there's no example of merkle trees in the original sources which contain additional data or metdata in the mid-tree nodes. But, to draw a parallel to compare to: we still very much consider "B+ trees" to be "trees", don't we?
If someone wants to coin "merkle-plus" trees to refer to merkle-trees with some data in mid-tree nodes, I wouldn't protest. But I'd also claim that the popular reference cat is out of the bag applies here in spades: a great deal of colloquial usage (such as the description of "git is a merkle tree") already supposes that data can be present in mid-tree nodes, both for structured labeling of child nodes, as well as for other data and metadata. I don't see any point in fighting this tide.
No, I don't think so.
(Not many systems seem to suggest this, but it seems worth clearing the air around it anyway while we're here, just in case.)
Some systems have been developed which absolutely rely on the lack of a fixed root and fixed depth offsets for children. For example, this USENIX 2009 publication on Efficient Data Structures for Tamper-Evident Logging scales the way it does because it grows up and to the right, with new roots forming every time the tree doubles in size -- and this literature heavily references merkle trees in describing its interior, and is part of well-reviewed and regarded literature.
... for your time and attention on this little rabbithole journey.