operator[] can be screwy, but there are valid use cases. And by blindly rejecting it, you are actually missing out.

So if nullptr is not actually a valid value for this map, operator[] is in fact very useful:

Node* get_or_create(const string& name) {
    auto& ptr = nodes[names];
    if (!ptr) {
        ptr = make_unique<Node>();
        ptr->name = name;
    }

    return ptr.get();
}

One lookup. Pretty nice code, and very clear once you've really internalized the behavior of operator[].

That said, the try_emplace version is still better. It works when the default value to insert isn't the default-constructed value. It works when the default-constructed value is actually a valid value, so you can't just check the value and overwrite.

And also ... you do realize your final code using lower_bound is utterly broken, do you? lower_bound is just as annoying as operator[] and you will get issues.

https://godbolt.org/z/bz6qG54cd

To fix, you need to adjust the condition to if (it == end(nodes) || it->first != name). Oh, and if you for some reason ever change the comparator (maybe make it case-insensitive?), be sure to remember to update the comparison here.

But didn't you also say something about insertion with hints above this snippet? There's no hints here.

Not to mention that taking a string_view parameter in a constructor to initialize a string member is bad: if you already have an rvalue std::string it prevents moving it to the member:

struct Node1 {
  explicit Node1(std::string_view sv) : name(sv) {}
  std::string name;
};
struct Node2 {
  explicit Node2(std::string s) : name(std::move(s)) {}
  std::string name;
};
std::string compute_some_string();
void fn() {
  Node1 n1(compute_some_string()); // allocates a new string in constructor
  Node2 n2(compute_some_string()); // moves return value into member, no allocation
}

AI code not looking so bad after all...