There's no case in which this can break. Word splitting is done prior to parameter expansion, so the assignment is safe without quotes, even when PATH has spaces in it.

My bad, it is actually repeatable. In bash, dash, busybox ash, and ksh93, the following works:

export PLAN9=/asdiu
export PATH='a b'
PATH=$PATH:$PLAN9/bin
export PATH

In bash, busybox ash, and ksh93, the following also works, but fails in dash:

export PLAN9=/asdiu
export PATH='a b'
export PATH=$PATH:$PLAN9/bin

This seems like it should be a bug in dash, export var=val should not behave differently from var=val; export var. But according to https://unix.stackexchange.com/questions/193095/where-is-export-var-value-not-available/193137#193137 it is a "known behavior", which sucks.

Either quoting the expansion or removing the word "export" should be valid fixes.

Since PATH is already an exported environment variable, you do not need to re-export it every time you modify its value. This is valid in all four shells I tested, and although I don't have the source at hand, I believe (and #bash on Freenode confirmed my belief) that this behavior *is* required by POSIX.

In view of the second comment, see also https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01. In short, the arguments conveyed to export do not count as "variable assignments" in the context of simple command grammar. Implementations of sh (dash included) are under no obligation to make export a special case just because it happens to be a builtin.

I'll add double quotes.