The problem is that you cannot properly describe HDR color space with a normal ICC profile. From technical perspective, the problem is that ICC cannot describe values higher than 1.0, which are a norm in scene-referred color spaces. From theoretical point of view (I’m not a pro in ICC details, so I might be wrong), the problem is that ICC does not operate with “nits” values. Instead, it expect diffuse white be the maximum available color brightness.
For example, PNG-HDR standard provides an ICC profile for p2020-pq color space (for backward compatibility), but if you pass this profile to a color management system and will try to convert colors to e.g. p2020-linear, all the color values will be clipped by 1.0. So the implementer should recognize this profile by a special tag and shape the colors accordingly.
So, if you want to implement a “color management engine” for a compositor, you should define a term “profile” in a bit broader way, than just an “ICC profile”.
EDIT:
There is also a problem of “feature completeness” of this engine. ICC pipeline has quite a lot of options and features and I am 99% sure there will be people who would report wish-bugs for some nice things like color proofing, blackpoint compensation and so on. I think that the main requirement here is that compositor at the very least must not prevent people from implementing these features inside the apps. Pass-through mode might help with it at least partially.
EDIT2:
Yes, unless ICC is the only means of describing color, then yes, HDR can be implemented quite easily. Though the devil hides in details: there is no commonly standard for describing HDR color 
Microsoft used enum tags for that, which is extremely bad: one cannot choose a custom color space for the buffer. There is even no tag for passthrough mode (DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 is technically a pass-though, because DXGI does no color management after compositing).