Issue 1:
[I still consider this somewhat incomplete, and I feel the suggestions for 'Declined' (hardest one) are not varied enough, but I felt it was valuable enough to post. I also subtly changed my mind on some of these during the weeks since this was written, but within the time constraints I feel this is the best I could do]

I've made my best to come up with alternative terms for the current labels. For inspiration I used the Roslyn, F#, Go and Rust issue trackers, and some originals of my own. The toughest one (by far) was Declined - It was so difficult I had to resort to opening a question on the 'English language and usage' stack exchange.

Examples of current best alternative label sets through the various stages of an issue

Positive outcome :-)

Feature Suggestion, Needs More Info

Feature Suggestion, Needs Specification

Feature Suggestion, Under Consideration

Feature Suggestion, Planned

Feature Suggestion, In Development

Feature Suggestion, Implemented

Negative outcome :-(

Feature Suggestion, Needs More Info

Feature Suggestion, Needs Specification

Feature Suggestion, Under Consideration

Feature Suggestion, No Foreseeable Plans, Not Enough Value

Positive outcome :-)

Enhancement Suggestion, Needs More Info

Enhancement Suggestion, Under Consideration

Enhancement Suggestion, Accepting Community Contributions

Enhancement Suggestion, Implemented

Negative outcome :-(

Feature Request

Feature Request, Outside Design Goals, Auxiliary Tooling Candidate

Positive outcome :-)

Bug Report

Bug Report, Confirmed

Bug Report, Confirmed, Fix Planned

Bug Report, Confirmed, Fixed

Negative outcome :-(

Bug Report

Bug Report, Needs Further Investigation

Bug Report, External: Edge

Negative outcome :-(

Enhancement Suggestion

Enhancement Suggestion, Needs More Detail

Enhancement Suggestion, No Foreseeable Plans, Taken As Information

Neutral outcome :-|

Feature Suggestion

Feature Suggestion, Needs Specification

Feature Suggestion, Subsumed, Taken As Information

Initial stage

Suggestion:

Intended meaning: "Any suggestion"

Problem: too broad, sometimes covers enhancements as well (which may also be seen as 'bugs' sometimes by the issuer), doesn't separate between "requests", "suggestions", and "specifications".

Suggestions: Split to possibly (or include as a secondary label)

Feature Request

Feature Suggestion

Feature Specification

Implementation Proposal

Enhancement Request

Enhancement Suggestion

Bug:

Intended meaning: "Confirmed Bug"

Problem: No way to label an unconfirmed bug.

Suggestions:

Bug Report, followed by

Bug Report and Confirmed

Needs More Info:

Intended meaning: "The team needs more information about this suggestion or bug in order to understand what's going on. Generally, Suggestions will start out as Needs More Info, graduate to Needs Proposal, then finally go to In Discussion"

Problem: doesn't separate "more info" from "further investigation".

Suggestions: split to

Needs More Info or Needs More Details

Needs Further Investigation (for bugs)

and possibly Under Investigation.

Needs Proposal:

Intended meaning: "A suggestion that has a well-understood use case and a plausible outline of a solution, but lacks a formal definition of how exactly the problem will be solved".

Problem: may be read as "please write a complete, detailed, formal implementation proposal or else this will not be considered".

Suggestions: Needs Specification, Requires Specification.

Review stage

In Discussion:

Intended meaning: "The suggestion is ready to be discussed at a Design Meeting or Suggestion Backlog Slog".

Actual usage: includes suggestions that are continuously discussed for relatively long periods of time.

Problem: could be interpreted as just being just "discussed" or as a "community discussion" or debate about a problem (my initial interpretation).

Suggestions: Under Consideration (inspired by the Edge platform status terminology), Under Review, In Review, Candidate Proposal, Candidate Suggestion.

Revisit:

Intended meaning: "A suggestion or bug that can't be adequately addressed today, but will probably be able to be addressed in the future (e.g. we need to wait for the ECMAScript committee to make up its mind)"

Problem: could be interpreted as referring to an old suggestion being "revisited" in the sense of it being "reconsidered' or 're-examined' (my initial interpretation).

Suggestions: For Future Review, For Future Consideration.

Outcome stage

Committed:

Intended meaning: "Someone from the TypeScript team will fix this bug or implement this feature"

Problem: highly ambiguous with Git 'Commit', could be read as "Implemented" (which was my initial interpretation and I still suspect I was right.. :) ).

Suggestions: Split to

Planned (Approved may also fit in some cases), for bugs maybe Fix Planned.

In Development

Fixed:

Intended meaning: "Was a planned bug-fix or feature but now implemented"

Problem: frequently applied to feature requests or enhancements as well.

Suggestions: Split to

Fixed for bugs

Implemented for features or enhancements (also, use Implements ##### instead of Fixes ##### in PRs to make it clear it is not actually a bug).

Addressed could cover cases that don't fit either one of them, like correcting a mistake in the specification or documentation.

Accepting PRs

Intended meaning: "We are accepting pull requests to implement this feature or fix this bug."

Problem: Is not clear on whether this also include pull requests from Microsoft team members?

Problem: not everyone knows what a "PR" is (Public Relations?)..

Suggestions: keep as-is or Accepting Pull Requests (if it includes Microsoft members as well) or Community Contributions Accepted (if not).

Declined:

Intended meaning: "For reasons explained in the issue, we are not going to accept this suggestion"

Actual usage: occasionally applied to ideas that are not really suggestions or specifications, or requests that were not originally presented as formal proposals.

Problems:

Excessively highlights the 'act' of proposing, or the personal 'appeal' of the issuing person, rather the interest of the design team in the idea at hand.

Could be seen as inappropriate for suggestions that have valid use cases but did not provide a good-enough solution (or not at all) or wide-enough set of applications.

Could be unconditionally interpreted as "we think this suggestion is bad or exhibits poor design therefore we reject it".

Too 'final' and 'verdict-like'. Doesn't really leave enough room for future reconsideration.

Doesn't feel very 'friendly' and may create a somewhat harsh atmosphere.

Suggestions (this was the toughest one by far): Split to:

No Foreseeable Plans: (or No Prospective Plans) for sound suggestions or proposals that have reasonable merit but for some reason were not deemed as appropriate or suitable for the language. This may be paired an additional label such as Not Enough Value or Auxiliary Tooling Candidate, described below.

Taken As Information: for suggestions that had valuable content but did not provide a solution that was seen as conforming to high enough standards (thanks to the StackExchange member who suggested this).

... Other ideas...

Other alternatives: No Team Interest, No Team Approval, or No Team Consensus for borderline ones (see the C# 7 feature work list for some inspiration.

By Design:

Intended meaning: "This is an intentional behavior of TypeScript"

Actual usage, includes:

Aspects of the language that were purposely designed with the belief they are good practices.

Design compromises or are known to be sub-optimal in some way.

Aspects that could have been done differently but are not possible or worthwhile to change due to it being a breaking change.

Aspects that are simply known to the designers, regardless of it being desirable or not, or being worthwhile to change or not.

Suggestions: Split to

Intended Behavior and

Design Limitation (other possible terms: Design Constraint, or Design Compromise.)

Out of Scope:

Intended meaning: "A suggestion that is outside the design parameters of TypeScript, either because it is a poor fit (e.g. make TypeScript look exactly like C#), is outside the constraints of the language (e.g. asm.js compilation), or better belongs to another tool or process (e.g. a built-in Collections library, or a runtime language feature that should start in the ECMAScript committee)".

Suggestions: Split to more specific cases:

Outside Design Goals

Requires ECMAScript Approval,

Auxiliary Tooling Candidate (or Third-party Tooling Candidate)

Externally Scoped

Duplicate:

Intended meaning: "This issue is the same, or has the same root cause, as another issue."

Problem: sometimes applied to somewhat different suggestions or enhancements that solve mostly the same problem set, but are simply preferred one over the other.

Suggestions: split to:

Duplicate for exact duplicates.

Converged, Subsumed or Assimilated for intersecting suggestions or enhancements.

Too Complex:

Intended meaning: "Relative to the complexity required to implement or understand it, the suggestion does not provide enough value."

Problem: could be read as "too difficult to implement" (my initial interpretation).

Suggestions: Not Enough Value, Not Worthwhile.

Won't Fix:

Intended meaning: "While the behavior described is agreed to be incorrect, the cost (in time, complexity, performance, etc.) is too high to justify taking a fix relative to the cost of simply living with the bug"

Problem: may be perceived to demonstrate an un-constructive or un-friendly attitude..

Suggestions: Not Enough Value, No Fix Planned, Not Enough Team Interest, No Foreseeable Plans.

External:

Intended meaning: "Catch-all bucket when an issue reported is not an issue with TypeScript, but rather an external tool, library, website, person, or situation".

Suggestions: leave as-is or consider extending the label to include the particular external entity referenced, e.g.:

External: Internet Explorer

External: ECMAScript

External: VS Code

External: Node

Questions and discussions

Question:

Intended meaning: "The issue is (intentionally or otherwise) simply asking a question about TypeScript. Answers to Questions, if provided, will generally be to-the-point because we do not have time to be a support community for all TypeScript users; please use Stack Overflow for TypeScript questions."

No alternative suggestions.

Discussion:

Intended meaning "This issue is a discussion with no defined outcome. The TypeScript team may weigh in on these issues, but they are not regularly reviewed".

Problem: a bit vague, can be confused with In Discussion.

Suggestions: leave as-is and rename In Discussion (see suggestions below) or use Community Discussion.

Canonical:

Intended meaning: "This issue contains a lengthy explanation of a common question or misconception".

Problem: unconventional usage of the term 'canonical' when applied to the issue itself. I'm not sure what the exact intention was but I believe it should mean 'recognized', 'well known', or alternatively 'authoritative'? (here's the dictionary entry for 'canonical').

Suggestions: Use a combination of two separate labels: Common Query (or Common Question) and Contains Reference Answer.

Misc and auxiliary labels

Infrastructure:

Intended meaning: "Technical debt associated with the TypeScript project".

Problem: could be read as meaning to do with things like the JS runtime, Node runtime, Chakra/V8 engine etc (my initial interpretation).

Suggestions: Technical Task, Technical Enhancement, Implementation Task, Implementation Enhancement.

Effort: Easy/Moderate/Difficult:

Intended meaning: "For issues Accepting PRs, these are an approximation of how difficult we think fixing the bug or implementing the feature will be. As a rough guide, fixing typos or modifying lib.d.s are generally Easy; work that requires understanding the basics of the codebase is Moderate; things marked Difficult will require an understanding that is rare outside the core TypeScript team."

Problem: 'Effort' does not naturally refer to a level of difficulty.

Suggestions:

Change to Effort: Low/Moderate/High or

Difficulty: Easy/Intermediate/High

High Priority:

Intended meaning: "Issues affecting runtime behavior or high-occurrence crashes"

Suggestions: leave as-is or use a granular label for each priority level like:

Priority: Low/Medium/High

ES6 / ES7 / ES Next:

Intended meaning: "Refers to issues related to features found in these specific ECMAScript versions".

Suggestions: consider updating to newer terminology and using more literal labels like:

Domain: ES2015/ES2016/ES2017

Notes: Some of these may be used in a complementary way, together, or sometimes in addition to the existing label. Some are two or three word long, which may seem a bit excessive, but that seemed inevitable to successfully convey clearer semantics.

Issue 2:
Edit 2/29: Update proposal based on design changes; moved 'Solution' to top since most people viewing this are familiar with the problems

Solution

Support a "native UMD" declaration form that allows for a global var to be of the type of a module.

A global module export declaration has the syntax:

export as namespace id;

where id is any Identifier.

This is only legal as a top-level declaration a .d.ts file containing other top-level export declarations (e.g. export function, export var, export =, etc.). Multiple of these declarations may appear in the same file so long as they supply different identifiers.

When the containing file is imported through import syntax, the declaration has no effect.

When the containing file is added to the compilation via a /// <reference directive or by being a top-level file provided to the compiler (e.g. on the commandline, or as part of tsconfig.json's files list), the supplied identifier[s] are added to the global scope of the program. The type of these identifiers is the type of the module object of the file in which they were declared.

These declarations may engage in module merging, though this should probably be discouraged somehow.

Example

my-lib.d.ts

export function doThing(): string;
export function doTheOtherThing(): void;

export as namespace myLib;

globalConsumer.ts

/// <reference path="my-lib.d.ts" />

myLib.doThing();

importConsumer.ts

import * as m from './myLib';
m.doTheOtherThing();

Problem

Many definition flies are written like this:

declare var Promise: {
// some stuff here
}
declare module 'bluebird' {
export = Promise;
}

Symptoms

This is bad for three reasons:

We can't find this file from normal module resolution, so it has to get into the compilation context through a 'reference' mechanism

This pattern can't handle the case where you have two versions of 'bluebird' because there is no path with which to disambiguate

People who are using the module version still get global scope pollution and might accidently use the global names when they meant to use an import name

Root Cause

The reason people do this (define globals, then export = from an ambient module declaration) is that the *reverse * (define a module, then declare a var with that module's type) is impossible.