Definitely looks like a bug (although the documentation is very unclear on what API Record instances actually have access to!).

Should reify be like this:

function reify(iter, seq) {
    return isSeq(iter) ? seq : new iter.constructor(seq);
}

?? That's just adding the 'new' keyword. It fixes your issue for me locally, but I don't know if it's the correct fix. An alternative might be

function reify(iter, seq) {
    return isSeq(iter) ? seq : iter.constructor.call(null, seq);
}

Not sure which fix is the better one!

although the documentation is very unclear on what API Record instances actually have access to!

Agreed. The docs are a little unclear on many of the instance methods IMO. I often end up just running them in the console and seeing what happens.

I believe this is by design. Record#map operates on this record's values, as opposed to returning a new record.

var r = new R();
r.toJS() // { foo: undefined, bar: undefined }
r.map(() => 10);
r.toJS() // { foo: 10, bar: 10 }

Having trouble understanding why any method that mutated an Immutable instance would be intentional.

That's a terrible behavior if it's intentional. A library called immutableJS should be 100% immutable, it's the sole reason it's useful.

lodash has the same trap: it started as a decent functional lib then added all sort of crap like _.pull, _.pullAt and _.remove to directly mutate arrays.

I don't see how this could be intentional.

It's undefined behaviour (since Record.map is not documented anywhere). But if the feature does become official, clearly this would be a straightforward bug, hopefully with a straightforward fix (if my fix above is the correct one, it's just a 4 character insertion). As everyone says, there is no way that <immutable object>.map() should modify <immutable object> (unless asMutable or withMutable is used, but map() isn't officially supported on mutable objects in any case).

See this issue: #505

Record.map should not be used.

Such methods should not be exposed or publicly accessible then.

Wow, this is an incredibly unexpected behavior. Our project heavily relies on Immutable.js and makes extensive use of Records. This behavior lead to several hours of debugging effort since I didn't think it was possible to mutate the properties of a Record instance once constructed. I offer this feedback not to complain, but to illustrate how seriously this behavior deviates from what I expect as a user of the library.

Hopefully this behavior is not intentional. #505 makes it sound like .map will eventually go away on Records, so hopefully that fixes this and any other ways to modify an instance of a record.

Merging into #505