The proposal's current description of \w leaves out connector punctuation such as underscore. See http://unicode.org/reports/tr18/#word . The definition there also explicitly adds marks to alphabetic code points.

See Unicode TR #18: http://unicode.org/reports/tr18/#Categories

What Perl does: http://docs.activestate.com/activeperl/5.10/lib/pods/perlunicode.html#unicode_character_properties
http://perldoc.perl.org/perlunicode.html#Unicode-Character-Properties

Note that JS would probably need to support \p{Cs} as well.

For backward compatibility (with Perl 5.6), all properties mentioned so far may have Is prepended to their name, so \P{IsLu}, for example, is equal to \P{Lu}.

XRegExp does the same, so it could be nice to support the Is prefix natively as well.

Generally I’d prefer to be strict and only support One True Way of doing things, though. For that reason I’d rather not support the aliases in PropertyAlias.txt and PropertyValueAlias.txt either.

The simplest form of extending the current (ES 2015) syntax would probably be extending RegularExpressionBackslashSequence with an optional Unicode property block. I've highlighted my diffs extending section 11.8.5 (Regular Expression Literals).

RegularExpressionLiteral ::
    / RegularExpressionBody / RegularExpressionFlags
RegularExpressionBody ::
    RegularExpressionFirstChar RegularExpressionChars
RegularExpressionChars ::
    [empty]
    RegularExpressionChars RegularExpressionChar
RegularExpressionFirstChar ::
    RegularExpressionNonTerminator but not one of * or \ or / or [
    RegularExpressionBackslashSequence
    RegularExpressionClass
RegularExpressionChar ::
    RegularExpressionNonTerminator but not one of \ or / or [
    RegularExpressionBackslashSequence
    RegularExpressionClass
RegularExpressionBackslashSequence ::
    \ RegularExpressionNonTerminator RegularExpressionNonTerminatorBlockopt
RegularExpressionNonTerminatorBlock ::
    RegularExpressionNonTerminatorBlockChar
    { RegularExpressionNonTerminatorBlockChars }
RegularExpressionNonTerminatorBlockChars ::
    [empty]
    RegularExpressionNonTerminatorBlockChars RegularExpressionNonTerminatorBlockChar
RegularExpressionNonTerminatorBlockChar ::
    RegularExpressionNonTerminator but not }
RegularExpressionNonTerminator ::
    SourceCharacter but not LineTerminator
RegularExpressionClass ::
    [ RegularExpressionClassChars ]
RegularExpressionClassChars ::
    [empty]
    RegularExpressionClassChars RegularExpressionClassChar
RegularExpressionClassChar ::
    RegularExpressionNonTerminator but not one of ] or \
    RegularExpressionBackslashSequence
RegularExpressionFlags ::
    [empty]
    RegularExpressionFlags IdentifierPart

This would make \p{…}, \P{…} and others part of the syntax, but note that this approach would make \d{…} syntactically valid, too.

I'm not sure if empty _RegularExpressionNonTerminatorBlock_s should make any sense at all. It would be an easy fix for the grammar to enforce at least one character in _RegularExpressionNonTerminatorBlock_s, but I have yet to find out if any RE engine supports empty blocks and how they behave if they see them.

http://unicode.org/reports/tr18/#Simple_Word_Boundaries or http://unicode.org/reports/tr18/#Default_Word_Boundaries? Or something else entirely?

See the UTS#18 <word_character> production:

The class of <word_character> includes all the Alphabetic values from the Unicode character database, from UnicodeData.txt [UData], plus the decimals (General_Category=Decimal_Number, or equivalently Numeric_Type=Decimal), and the U+200C ZERO WIDTH NON-JOINER and U+200D ZERO WIDTH JOINER (Join_Control=True).

However, http://unicode.org/reports/tr18/#b says:

If there is a requirement that \b align with \w, then it would use the approximation above instead.