Two different lines in my own Emacs config call the exact same function twice, in the exact same file, a few lines apart. Neither one breaks anything. Both are worth understanding, because they demonstrate two different things about what use-package actually guarantees — and neither one is what I assumed before I went looking.
The first: once in :config, once in :init
core/vc.el has this use-package block for diff-hl:
(use-package diff-hl:ensure t:after magit:config(add-hook 'magit-pre-refresh-hook 'diff-hl-magit-pre-refresh)(add-hook 'magit-post-refresh-hook 'diff-hl-magit-post-refresh)(add-hook 'diff-hl-mode-hook 'diff-hl-show-hunk-mouse-mode)(global-diff-hl-mode 1)(diff-hl-flydiff-mode 1)(diff-hl-dired-mode 1)(diff-hl-margin-mode 1)(diff-hl-amend-mode 1):custom(diff-hl-update-async t):init(global-diff-hl-mode 1):hook (diff-hl-mode . (lambda () ...)))
(global-diff-hl-mode 1) appears twice — once inside :config, alongside the four other diff-hl-*-mode calls, and again alone inside :init, several lines later. use-package's :init form runs before the package is loaded, and :config runs after — so this isn't a copy-paste inside one block, it's the same call sitting in two forms that execute at two different times. Calling an already-enabled global minor mode function a second time is harmless; the mode just gets toggled on again, which does nothing observable if it was already on. But it's redundant work happening twice for no functional gain, and the only way it makes any sense is as leftover from restructuring the block at some point without checking whether the original call was still needed somewhere else in it.
The second: once via use-package, once bare
core/ui.el has a similar pattern with ivy-mode, but shaped differently. Inside use-package ivy's :config section:
(ivy-mode 1)(counsel-mode 1)
Seventeen lines later, after the use-package block has already closed and a couple of unrelated keybindings have been set, there's a second, completely bare pair of calls sitting at the top level of the file:
(require 'ivy)(ivy-mode 1)
This one is a slightly different shape of the same mistake. The first (ivy-mode 1) already runs the moment the ivy package finishes loading, since it's inside that package's own :config. The second is an explicit, manual (require 'ivy) followed by calling the mode function again — as if written by someone who'd forgotten Ivy was already being configured a few lines up in the same file, or who added it while debugging something else and never removed it afterward.
Why neither one is actually a bug
Both global-diff-hl-mode and ivy-mode are ordinary minor modes, and calling (some-mode 1) on a mode that's already on is idempotent by design — Emacs minor modes are built around toggle functions that take an explicit argument specifically so "turn this on, and it's fine if it's already on" is always a safe thing to write. That's exactly why this kind of duplication can survive completely unnoticed for as long as it has: nothing about running the file produces different behavior, a different startup time worth noticing, or an error. The only cost is entirely at the reading level — a maintainer or a future version of me looking at either file and reasonably wondering whether the two calls are doing different things, when they're not.
What :init versus :config actually promises
The general lesson from the diff-hl case specifically is about ordering, not safety. :init code in use-package runs unconditionally, before the package is guaranteed to be loaded — it's the right place for setting variables the package will read once it does load. :config code runs only after the package has actually loaded, which is where calls that need the package's functions to already exist belong. Putting the same mode-enabling call in both places doesn't cause a conflict, because both are valid places to call it from — but it does mean the block no longer tells an honest story about which one was actually necessary. Reading a use-package form should tell you what has to happen before load and what has to happen after; once the same call shows up in both, that signal is gone, and the only way to know which one is load-bearing is to delete one and see if anything changes.