虽然这是一个旧问题，看起来并不是非常重要（实际上本身并不是非常重要），而且它已经得到了相当不错的答案，但我会尝试回答，因为它涉及到标准演变和基于现有语言设计语言时的基本问题：何时应该废弃、删除或以不兼容的方式更改语言特性？
在C++中，可以在翻译单元内使用static关键字来影响符号的可见性（无论是变量还是函数声明）。
实际上是链接性。
在n3092中，这被弃用了：
弃用表示：
- 有意在未来删除某些功能；这并不意味着弃用的功能将在下一个标准修订中被删除，或者它们必须很快或根本不被删除。而非弃用的功能可能会在下一个标准修订中被删除。
- 正式尝试阻止其使用。
后一点很重要。尽管从来没有正式承诺您的程序不会被下一个标准打破，有时甚至是悄无声息的，但委员会应该尽量避免打破“合理”的代码。弃用应该告诉程序员：依赖某些功能是不合理的。
它确实强调了与C的兼容性（以及将C程序编译为C++的能力）的问题，这种弃用很让人恼火。然而，直接将C程序作为C++编译可能已经是一种令人沮丧的体验，因此我不确定它是否值得考虑。
保留C/C++公共子集特别重要，特别是对于头文件。当然，全局static声明是具有内部链接的符号声明，在头文件中并不非常有用。
但问题并不仅仅是与C的兼容性，也涉及到与现有的C++代码的兼容性：存在着大量使用
static全局声明的有效C++程序。这些代码不仅在形式上合法，而且还是正确的，因为它们使用了一种明确定义的语言特性，按照其预期的方式使用。
仅仅因为现在有一种“更好的”方法（根据某些人的说法），并不意味着用旧方法编写的程序“不好”或“不合理”。在C和C++社区中，使用
static关键字在全局范围内声明对象和函数的能力是被很好理解的，而且通常被正确使用。
类似地，我不会将C风格的强制类型转换更改为
static_cast<double>，只是因为“C风格的强制类型转换是不好的”，因为
static_cast<double>没有增加任何信息或安全性。
每当发明一种新方法来做事情时，所有程序员都会匆忙地重写他们现有的、经过良好定义的工作代码的想法是完全不切实际的。如果您想消除所有继承自C的丑陋和问题，您不应该改变C++，而是应该发明一种新的编程语言。 半删除
static的一个用法并不能使C++不那么C丑陋。
代码更改需要有理由，只是因为“旧的不好”从来都不是代码更改的理由。
破坏性的语言更改需要非常强的理由。让语言变得稍微简单一点从来不是对破坏性变更的正当理由。
给出的
static不好的原因非常薄弱，甚至不清楚为什么对象和函数声明不能一起被弃用——这样做并没有使C++更简单或更正交。
因此，真正令人悲哀的是这个故事。不是因为它产生了什么实际后果：它完全没有实际后果。而是因为它显示了ISO委员会缺乏常识。
static在未命名命名空间不起作用的地方；而这里的答案似乎主要基于个人意见。 - legends2k