let a = "hello";
console.log( a );
let a = "goodbye";
What you're referring to is the fact that when you expand an object or array in the console, then you see the contents of that object or array at the time you expand it, not as it originally existed when console.log() was called.
This is why alessioalex's sibling comment is so useful. By logging the output from JSON.stringify(), you are logging a string whose value will not change.
This log is still synchronous, but when you expand it in the console its properties are dereferenced and may be different from when the original log was made. The log, however, is still instantaneous and synchronous.
It was because one message was console.info and another was console.error, which was going to stderr and so getting flushed differently.
A couple months ago I fell for it again.
If JavaScript devs don't know if a function is async or sync it just gives more evidence that JS is a monkey-language. LOL!
A function can call a third party service, or some subsystem running on the same computer, whatever. Regardless of the programming language, that service may or may not do stuff asynchronously after your call. There's no way to tell. I regard the console.log to be a third party service. Who the heck knows what it does, except it has access to your memory!
As for a third party service argument, you're just stretching the goal posts there to fit your argument.
I agree that the core language is not the worst problem with JS; that's what I was trying to say.
Regarding the other point about knowing whether something is async or not. Few languages will tell you if a function does side effects. They might spawn threads or processes, mutate the data you sent them, all after the call has returned. Languages where you can easily see that this will happen are few and far between, and they have strong static type systems.
If the objects to be printed change between console.log() and the actual printing, the output you see may not represent the state when console.log() was called.