SSE3 movddup xmm, xmm/m64 is a 64->128 broadcast.
Interestingly, the AVX1 256-bit version (vmovddup ymm, ymm/m256) does two separate in-lane broadcasts, and has a 256-bit memory source. But with a memory source, it still runs purely on a load port on Intel CPUs, like broadcast-loads.
As you say, vbroadcastsd ymm, m64 is AVX1, vbroadcastsd ymm, xmm is AVX2, and there is no vbroadcastsd with an XMM destination.
If it wasn't for the memory-source-only nature of AVX1 broadcasts, Intel might have just made the 256-bit version of movddup be vbroadcastsd. i.e. 128-bit vmovddup and vbroadcastsd could have been aliases for the same opcode.
But splitting them up let Intel make a m64 -> ymm broadcast for AVX1, while still providing vmovddup xmm, xmm/m64 with the source allowed to be a register. I don't know why the provided a 256-bit in-lane-broadcast version. Maybe that's actually useful sometimes, or they could do it cheaply.
If vbroadcastsd is encoded with VEX.L= 0 (implying 128-bit vector width), the manual explicitly says it will #UD. So there isn't an undocumented 128-bit version.