The bug
This results in vines with either a full block's hitbox (1.12.2) or no hitbox (1.13-pre), but visually they look like they're set to south. These vines are also mostly unaffected by randomTickSpeed and thus will never decay/grow. An exception to this is if you setblock the vine next to any block(s) that it's able to attach to, in which case it'll automatically update its blockstate to match a nearby block upon being randomly ticked (note that updating the block itself by placing other blocks will break an all-false vine; it has to be updated by a random tick). All-false vines can still be climbed though.
Probably related to MC-85967, which was seemingly very questionably marked as WAI for the simple reason of "because you can't climb them without a block behind it", despite that statement being technically untrue even back then (there just needs to be a solid wall within climbing range). This might technically be a dupe of that report, but I figured this one has a bit more info in the title/description, as well as behaving slightly differently across versions (what happens in the other report's version seems to match 1.13-pre, while 1.12.2's bugged vines actually have a hitbox).
Either way, this clearly seems like a bug, not WAI. South-facing vines seem to be the intended default judging by the visuals. If all-false is WAI, then for example why aren't cobblestone walls the same? Their "up" value is true by default when running these commands, whereas going by how it works with vines, you'd expect it to be false. Not to mention block updates destroy all-false vines, even if it you place an attachable block on the visually correct side (which is kind of a minor and moot point anyway admittedly, since I don't think all-false vines can spawn naturally).
How to reproduce
/setblock ~ ~ ~ vineLook at the vine
❌ It has no hitbox
Linked issues
duplicates 1
Comments 3
Yeah I'm not entirely sure either, but at the very least it's completely missing its hitbox when all of its states are set to false, which doesn't seem right. Then again, the hitbox for vines seem to have changed in 1.13 in the sense that it only has a thin hitbox on each side set to true (thin vine hitboxes exist in 1.12 as well, but only when a single face is set to true). So the missing hitbox thing in 1.13 might actually be WAI since it technically has no faces.
Also I don't think it's quite the same situation for redstone wires, since their default "all-false" state (technically they have "directions" rather than true/false states) is to just be a single blotch on the ground.
In the end, I think this might actually be more of a problem of the southern vine face being rendered despite everything being set to false. Maybe vines should be the same as all-false cobblestone walls in regards to total invisibility? That could for example give it use as a niche invisible fall damage prevention block for map creators, or a fake slowfall (not sure if a bug (it's inconsequential if so; beneficial in fact), but unlike in 1.12, vines aren't updated by blocks placed below them in 1.13, so it's/it'd be possible to make a fake slowfall/invisible ladder).
This should be forward resolved to MC-85967
Unsure, if this might be WAI.
Redstonedust for instance does get placed with the inferred blockstate, when using setblock.
Vines might not do this, because when placed by hand they only connect to the block they were placed on (that you are facing). This does not apply when placing with a command.
MC-85967 is WAI imo because the vine does not have any block to connect to and thus should use the false states. It's just weird that the south side is visible regardless.