Here's a test upstream patch:
http://bugs.icu-project.org/trac/ticket/13288

I haven't given any thought to the impact of jumbo-build on what digit@ wants to for Android in https://chromium-review.googlesource.com/c/522667 .  It may or may not have any impact. Just in case, I'm adding him here along with this note. 

 
In the worst case, if jumbo build interferes with the above CL, we can disable jumbo build for Android. 

Thanks. I don't see a huge problem here, my patch essentially changes the set of source files that are compiled into the ICU library

(i.e. remove the sources related to collation, and add new ones that implement the same features though function pointers to the system library).

I don't know exactly how the jumbo source file (the one that includes all other C sources) is generated, but if it is automated from the BUILD.gn rules, the only bad thing I can see is a naming conflict that I should be able to resolve on my side.

In other words, feel free to proceed, I'll adapt accordingly :)

Thanks a ton for your consideration though!

Isn't this fixed? 

I can't find any signs that icu uses jumbo so I think all that landed was making the code jumbo compatible (no duplicate symbols). I'd be reluctant to adding jumbo to icu at the moment since it's already compiling fairly quickly and it's a third party repo. Maintenance with third party repos can be frustrating with the need to do quick rolls when a roll has broken jumbo compilation.

It's better now when we have a jumbo bot in CQ but it only tests Linux small (goma) jumbo chunks, and there are breakages from using larger chunks (default outside goma) or in Win and Mac it won't find.

Upstream wanted to know how large the patchset would be up front instead of accepting small patches as I made progress, and so this task has stalled.

In the meantime, we have the JumboSupport Clang plugin project, which could simplify things greatly- it we can manage to get the Clang hooks accepted.