Happens on all operating systems, not just Mac.

I looks like the characters are actually in the DOM, but not visible.  Even if a font is available for the invisible character, it will not be visible.  The bug affects the console log as well.  However, it is possible to select and copy the string and paste into another application, either from the DOM or the console log.

It is more than just UTF-16.  UTF-32 strings are also having problems when inserting with &#xCODEPOINT; references, such as 􀀁

This was fixed a couple of months ago. Please upgrade to a recent version of chrome and retest.

I'm glad this was fixed.  Do you know what version fixed this issue?

I am using the current stable release of Chrome/Chromium on the various operating systems.  Do I need to install a development releases to verify the fix?  How long until the stable releases catch up with the fix?

This is NOT fixed in v50, v51, or Canary.  The problem still exists.

Reopening per comment 7

To open the test URL in Canary, you need to use the full view:
http://codepen.io/Slevinski/full/dMNVag/

I am able to reproduce this issue on Latest Canary#51.0.2688.0, Dev#51.0.2687.0, Beta#50.0.2661.37 and Stable#49.0.2623.87 versions of chrome for Win7 64-bit OS, Mac OS X 10.11.4 and Linux Ubuntu 14.04.

This is not a Regression and observing the similar behavior from M26: 26.0.1410.46. Attached the screenshot for your reference.

Thank you!

I updated Canary  to Version 51.0.2688.0 and tried again.  Much better.  There still seems to be a problem for characters U+E0001 thru U+E0FFF, but that's it.

For my work, characters on plane 15 and plane 16 are working as expected.  Thanks for the consideration.

Re: 12: Thanks for verifying. We'll try to add fallback fonts for the remaining codepoints.

Re 11: Oh, the soft/light rendering is a separate problem then we're talking about here. 

Thanks for the report. 

The underlying issue was an integer truncation issue in our character test functions, marking as duplicate of  issue 595960  in which this was identified as the root cause.

> There still seems to be a problem for characters U+E0001 thru U+E0FFF, but that's it.

U+E00001 to U+E001EF are from the 
https://codepoints.net/supplementary_special-purpose_plane
Language Tags and Variation Selectors. 

Compare http://unicode.org/faq/unsup_char.html#3 for guidelines on how to display those. We render this range as zero width spaces and in that sense follow the Unicode standard.

HarfBuzz shaping output for testing U+E00001:
../test/shaping/hb-unicode-encode "DB40 DC01" | ./hb-shape /Library/Fonts/Times\ New\ Roman.ttf 
[space=0+0]

(which means that U+E00001 is rendered using the space glyph with a zero advance width. So I believe the Canary rendering is correct, in fact for characters for the supplementary special purpose plan more correct than Firefox.

Thanks for the explanation about the supplementary special-purpose plane.  Makes perfect sense.