We lost the optimizations introduced with CLJS-1884, but it looks like they can be re-gained with 3 conversions of with-meta to -with-meta.
On a simple program that does (prn :hi) you can see the output drop from 96,990 bytes to 89,429 bytes.
CLJS-3118.patch converts to -with-meta in 3 places:
In MapEntry this appears to be OK as it is being applied to a vector literal.
In vec and set, with-meta is previously applied to values that satisfy vector? and set? respectively. Assuming these non-nil values don't also satisfy goog/isFunction then with-meta would then call -with-meta on them. So, this change could also be a slight perf optimization owing to the inlining and elision of a few checks.
If, on the other hand, a value satisfying goog/isFunction is passed to vec or set and causes the code to follow this path (by satisfying vector? / set?), then correctness of the change would also seem to depend on whether that value properly implements -with-meta. It seems you would only get into this situation if code does odd things like
CLJS-3118.patch passes CI
CLJS-3118.patch added to Patch Tender
CLJS-3118.patch passes Canary