It has always been the case. Keys are returned in bucket order, then top to bottom. Keys that collide into the same bucket will be stored in LIFO order. When copying a hash like so:

%copy= %orig;
[download]

%copy will be identical to %orig only if the the size of the bucket array is the same and no buckets collide. If the size of the bucket array is different the key order will change.

$ ./perl -Ilib -MHash::Util=bucket_array -MData::Dumper -le'my (%hash,
+%copy); keys(%copy)=16; %hash=(1..14); %copy=%hash; print Data::Dumpe
+r->new([bucket_array($_)])->Terse(1)->Indent(0)->Dump for \%hash, \%c
+opy;' 
[['13','5'],1,['7'],['11'],2,['3','1'],['9']]
[3,['11'],3,['9'],['5','13'],1,['7'],3,['1','3'],1]
[download]

Even if the bucket size is the same if items collide then during the copy they will reverse order relative to each other.

$ ./perl -Ilib -MHash::Util=bucket_array -MData::Dumper -le'my (%hash,
+%copy); %hash=(1..14); %copy=%hash; print Data::Dumper->new([bucket_a
+rray($_)])->Terse(1)->Indent(0)->Dump for \%hash, \%copy;' 
[['11'],['7'],2,['13','5'],['9','3'],['1'],1]
[['11'],['7'],2,['5','13'],['3','9'],['1'],1]
[download]

None of this is new. The only new thing that changes here is which keys collide, and the fact that for a given list of keys, with hash randomization eventually they will all collide with each other. Before if you were lucky and your keys didn't collide, such as in tests, then broken code might work. At least until some new key was added that changed the state of the hash.