Thanks for filing the issue. Able to reproduce it for chrome version 55.0.2883.95 on MAC OS and 55.0.2883.87 on Windows and Linux OS. issue is a regression broken in m52 builds. Below are the bisect details for the same:

Bisect Info:
============
52.0.2721.0 - Good Build
52.0.2722.0 - Bad build

Change Log: https://chromium.googlesource.com/chromium/src/+log/13905ccd656349df4ec5e9bf196d4bc913a0a97b..dcdc0218d3404fb53a1b27f40b3ebed5dd5e277d

Suspecting Below change could be a possible culprit:

https://chromium.googlesource.com/chromium/src/+/dcdc0218d3404fb53a1b27f40b3ebed5dd5e277d

@kozyatinskiy: Assigning to you. Kindly have a look into it. Please help us to find an owner if not with respect to your change.

Thanks.!

Hm. It looks like it works as intended, console object is regular JavaScript object and when your remove property on js object you wouldn't able to get its value.
Why is it important in your workflow?

In some cases, console.log is being abused by 3rd party libraries in order to output debug properties. In many of these cases, there is no provided way to stop these console.log outputs from appearing (ie, 'debug:true|false' in config), and they quickly become an issue on production (when removing them via a build process is not possible). The old behavior was that you could rewrite the console.* statements to a no-op function and 'mute' them in production with a method to restore. When using a 'debug:true' flag set in localstorage, we were able to restore those console.log outputs in order to debug production by running 'delete' on these properties, and Chrome would return the built-in logging. This is no longer the case, and so, when these console.log statements are muted, there's no way to optionally restore them.

I realize this is a strange and edge use case, and I'm up for some debate around ways to disable console.logs, but this was a simple, reliable, easy behavior to work with. Not totally clear with the reasons behind the change, they're likely justified, but it squashes some things for me and my team. If this isn't realistic to restore, let me know and we'll have to go back to the drawing board.

I also wanted to add, that this exact same behavior works the way I describe in Node, attaching some scrollback here.

Deleted: mutelogs-node.txt 183 bytes

mutelogs-node.txt 183 bytes View Download

Could you run code like following before all frameworks?

var log = console.log;
console.log = function() {
  if (localStorage.debug) {
    log.apply(null, arguments);
  }
}

Only in some cases, as some of these libraries (like them or not) are mandated to load at a specific point in the page's lifecycle, and so, this could help 'stem the bleeding' for sure. Is there a technical reason to change this behavior? Seems dangerous to allow the user to nuke stock browser functions, however, I'm totally unaware of the background challenges.

Please file an issue in the console spec repo: https://github.com/whatwg/console
According current spec draft console is almost regular JS object and removing field from this object is the same as removing field from global object or any other DOM APIs for example.