UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36 OPR/43.0.2442.806

Steps to reproduce the problem:
1. Try and do something interesting with a chrome devtools extension

What is the expected behavior?

What went wrong?
The chrome.devtools API is severely restricted in terms of what you can do.  Things that seem like basic tasks become really complicated when you try to cover many use cases.

For instance, I'm trying to do the following:

 - Monitor requests for a script, then when the script loads execute some code in the same context.  This is harder than it seems, as you can only pass a frameUrl option to inspectedWindow.eval().  A frameUrl is not always unique on the page.
 - Highlight an element on page in a fashion similar to hovering over an element in the Elements panel.  Most approaches would involve modifying the CSS of the element in the page, but this has many drawbacks, not least the fact that you're no longer just an "observer".
 - Obtain worker contexts and execute code in them.  I don't currently see a way to do this.
 - Create, hold a reference to and repeatedly work with an object that is unavailable to the page.

And more.  Some problems I've written overly-complicated workarounds for (like the first issue).

Did this work before? N/A 

Chrome version: 56.0.2924.76  Channel: n/a
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0

I could file separate issues for each of my problems, but I feel like exposing the debugger protocol as an API would make much more sense and give much more freedom and power to extension developers.

Internally, the dev tools could use request/response IDs to track requests initiated from an extension separately from the main devtools requests.  A Promise-based API would also bring the dev tools up to date with modern async practices.