Is wanting a div to be focus-able a good use case for contentEditable?

The documentation says

suppressContentEditableWarning
Normally, there is a warning when an element with children is also marked as contentEditable, because it won’t work. This attribute suppresses that warning. Don’t use this unless you are building a library like Draft.js that manages contentEditable manually.

Well I'm not building a library which manages contentEditable manually, but I think I have a situation that contentEditable makes sense for that - if yall agree - might be good to update the documentation for.

I am building a sort of inline-editable component which will toggle between "view" and "editable" versions of their rendered contents. So my render method looks like this

  render = () => (
    <EditableContainer className={classnames({ 'has-spinner inline': this.state.saving })}>
      {this.state.editing ? (
        this.props.renderEdit({
          value: this.state.currentValue,
          onChange: (currentValue) => this.setState({currentValue}),
          onKeyDown: this.onKeyDown,
          onBlur: this.save,
          ref: this.editRef,
        })
      ) : (
        <div contentEditable suppressContentEditableWarning onFocus={this.transitionToEdit}>
          {this.props.renderView({value: this.props.value})}
        </div>
      )}
    </EditableContainer>
  );

  transitionToEdit = () => {
    this.setState({editing: true, currentValue: this.props.value}, () => {
      if(this.editRef.current)
        this.editRef.current.focus();
    });
  }

Note that I wrap the "view" component in a contentEditable div, this is primarily so that it can obtain focus and is in the natural tab order. Once it is tabbed to, I actually no longer render it, instead switching directly to the "editable view". So I'm pretty sure the warning is moot since - nothing can actually happen within the contentEditable, it can trigger and...that's about all, however it is needed in order to properly allow focus without manually managing tabIndex.

Is this a valid use case? If so, I would recommend updating the documentation to say something like

Don’t use this unless you are building a library like Draft.js that manages contentEditable manually. You may also use it to allow focus to shift to otherwise unfocusable element but beware that actually using the contentEditable component might step you outside the bounds of what React can properly control.

Start with the suppressContentEditableWarning section in the React DOM elements documentation linked in the issue and review the proposed wording against the described focus and tab-order use case. Confirm the documentation guidance and update that section if appropriate; done when it accurately explains the supported use case and caveat.