I figure that while the original motivation for the minotaur not respecting Elbereth may no longer apply, the game is more interesting when you have to gameplan for a monster that is physically strong, magically weak, and ignores Elbereth completely.

I believe this change would go against the general principle driving many monster changes in 3.7 by making minotaurs more boring instead of more different and interesting.

I believe this change would go against the general principle driving many monster changes in 3.7 by making minotaurs more boring instead of more different and interesting.

This is not the place for that discussion.

This PR fixes issue #47, which was opened Sep 14 2017. If the devteam felt this was a bad change, they could have closed that issue any time in the last 8.5 years.

I felt it was better to comment on the pull request implementing the change because it's newer and it's less likely that people looking at this thread will go check on the issue to see if there are any dissenting opinions.

Unfortunately I do not think we can take an issue's long lifetime as a sign of general acceptance by the devteam - they do not appear to have any procedure in place to deal with suggestions that fail to achieve consensus or that none of them who looks at github is interested in merging. (case in point, the next oldest open issue #100 which adds something no one asked for or wants... still open after 7 years.)

I felt it was better to comment on the pull request implementing the change because it's newer and it's less likely that people looking at this thread will go check on the issue to see if there are any dissenting opinions.

This PR should stay focused on reviewing the implementation and getting the code merged.

Broader discussion about the problem itself, scope changes, or design direction belongs in the linked issue. That keeps the conversation structured the way GitHub intends: issues track the “what” and “why,” PRs review the “how.”

Mixing the two makes the review harder to follow, buries actionable feedback in noise, and muddies the project history for anyone looking back later.

Please move the issue-level discussion to the issue so we can keep this PR clean and reviewable.

Thanks.