One of the common problem an Emacs newbie would commit is take defvar literally, that is to define an variable. But I don't think it's all the user's fault, because the name is misleading. The defvar can associate a non-nil value with an variable only once.

 
ELISP> (defvar aa 3)
aa
ELISP> aa
3 (#o3, #x3, ?\C-c)
ELISP> (defvar aa 4)
aa
ELISP> aa
3 (#o3, #x3, ?\C-c)
ELISP> (setq aa 4)
4 (#o4, #x4, ?\C-d)
ELISP> aa
4 (#o4, #x4, ?\C-d)
 

The story always goes this way: you use defvar to modify an variable, and then execute eval-buffer to reevaluate it, and hope to see the changes, but nothing changes, you never doubt the defvar and try to find causes in other places(in a complex environment people tend to not doubt the easiest part but those harder parts), of course you will not find it, at the end you will find you made such a stupid error and learn the lesson from it.

Honestly, I think it's counter intuitive, almost all other languages haven't such a rule, this will definitely a surprise for most people. Think about what it looks like when apply this rule to function. You will need a macro to "define" or "declare" the function and another macro to change the function body.

In essence, it's an ontology problem, in the vocabulary of Emacs lisp, define has a different meaning from the common consensus of the outside world. The rule of thumb is don't treat source code as English even they are written in English-like style, those names can mean anything the author or the community want they to mean.